[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P63DY3TGA3ZJCMRM267KH7":3,"skill-same:01M6P63DY3TGA3ZJCMRM267KH7":96},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":74,"commitSha":75,"skillDirectory":76,"forksCount":77,"repositoryHtmlUrl":78,"repositoryHomepageUrl":6,"ownerHtmlUrl":79,"ownerBlogUrl":80,"ownerDescription":6,"updatedAt":81,"install":82,"resources":95},"01M6P63DY3TGA3ZJCMRM267KH7","convergence-gate",null,"Runs a structured 7-phase convergence session to arrest strategic drift after 3-4 Sonnet feature sessions. Use when the drift-detector fires YELLOW or RED, or when you notice accumulating uncommitted state, deferred validations, and growing open-items lists.","DojoGenesis\u002Fgateway","DojoGenesis","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273886418?v=4","01M6P54RXMD3TZ2082Z3Z4JMQP","Cruz Morales (TresPies)","01M6P54S269YR0ZZZ96WGQM439",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fsystem-health\u002Fskills\u002Fconvergence-gate\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"convergence gate","convergence","gate","reset","count","opus","sonnet","you","notice","STRING","false","commit","feature","drift","system","markdown","why","open","Evaluation","run","2026-11-10 10:12:30",false,"---\nname: convergence-gate\nmodel: opus\ndescription: Runs a structured 7-phase convergence session to arrest strategic drift after 3-4 Sonnet feature sessions. Use when the drift-detector fires YELLOW or RED, or when you notice accumulating uncommitted state, deferred validations, and growing open-items lists.\ncategory: system-health\nversion: 1.1.0\ntriggers:\n  - \"drift detector fires RED\"\n  - \"drift detector fires YELLOW\"\n  - \"run convergence session\"\n  - \"arrest strategic drift\"\n  - \"convergence gate\"\ntier: 1\nagents:\n  - \"primary\"\ntags: [convergence, drift, hygiene, governance]\ntool_dependencies:\n  - \"file_system\"\n\ninputs:\n  - name: trigger_reason\n    type: string\n    description: Why convergence is being run — YELLOW drift warning, RED drift warning, or manual call\n    required: false\noutputs:\n  - name: convergence_report\n    type: ref\n    format: markdown\n    description: Updated convergence ledger entry with session count reset, commit sweep results, triage decisions, and strategic evaluation\n---\n# Convergence Gate Skill\n\n## Philosophy\n\nSonnet sessions produce excellent artifacts but poor trajectory. Each session is locally optimal — clean build, tests pass, seed captured — but globally drifting: more open items, more uncommitted state, more deferred validation. The missing discipline is periodic evaluation of trajectory, not just output.\n\nConvergence is not a feature session. It produces no new features. It produces a clean, tested, committed, evaluated state — and a reset counter so the next cycle starts from solid ground.\n\nThe drift-detector.sh hook enforces this mechanically, but the convergence gate skill is the procedure that actually runs when the hook fires.\n\nConvergence also enforces two deployment disciplines: a **pre-deployment readiness check** that forces full build\u002Flint\u002Ftest\u002Fe2e verification before any release, and a **deployment retrospective** that captures friction from recent deploys before it evaporates.\n\n## When to Use\n\n- When `drift-detector.sh` fires a **YELLOW warning** (10+ dirty files OR 4+ sessions since last convergence)\n- When `drift-detector.sh` fires a **RED warning** (25+ dirty files OR 6+ sessions)\n- When open-items lists have been growing across multiple sessions without resolution\n- When multiple deferred validations (tests, build checks, config audits) have accumulated\n- When you sense \"things are going well\" but can't clearly articulate what the next priority is — that ambiguity is exactly what convergence resolves\n\nDo not use this skill for feature work. Convergence sessions produce zero new features. Any fix discovered during convergence is logged and deferred — never implemented in-session.\n\n## Workflow\n\n### Phase 1: Inventory\n\n**Objective:** Establish a complete picture of the current state before touching anything.\n\n1. Run `git status` across all active repos to count dirty files and identify untracked paths.\n2. Read `~\u002F.claude\u002Fconvergence-ledger.md` to confirm session count since last convergence.\n3. Identify the drift severity: YELLOW (10+ files or 4+ sessions) or RED (25+ files or 6+ sessions).\n4. List all open items from CLAUDE.md, MEMORY.md, and any active TODO files — do not edit them yet.\n5. Identify deferred validations: any `go build`, `go test`, migration checks, or connectivity tests that were skipped in prior sessions.\n\nOutput of Phase 1: a flat inventory list. No judgments or actions yet.\n\n### Phase 2: Commit Sweep\n\n**Objective:** Commit all work-in-progress that is ready to ship.\n\n1. For each dirty repo, determine if the changes are shippable (build passes, tests pass, intent clear).\n2. Run `go build .\u002F...` and `go test .\u002F...` before staging any Go files.\n3. Commit shippable changes with conventional commit messages (`feat:`, `fix:`, `chore:`, `docs:`).\n4. For changes that are NOT shippable, document the blocker in the convergence ledger and leave them staged or unstaged — do not force-commit broken state.\n5. After all commits land, confirm `git status` is clean (or explains each remaining dirty file).\n\n### Phase 3: Deferred Validations\n\n**Objective:** Run every validation that was skipped or deferred in previous sessions.\n\n1. Execute each deferred check from the Phase 1 inventory.\n2. For each validation:\n   - **Pass:** note it in the ledger and close the deferred item.\n   - **Fail:** document the failure, its probable root cause, and the specific fix needed — but do NOT implement the fix in this session.\n3. Config checks take priority: scan `settings.json`, `.env`, `wrangler.toml`, and any gateway config for stale URLs or missing keys before debugging any code.\n4. MCP server connectivity: verify each configured server responds before reporting any MCP tool as broken.\n\n### Phase 4: Open Items Triage\n\n**Objective:** Decide the fate of every open item — resolve, defer, or kill.\n\n1. Read through the accumulated open items list from Phase 1.\n2. For each item, assign one of three dispositions:\n   - **Next session:** high priority, unblocked, clear definition of done.\n   - **Parking lot:** valid but not urgent; survives to next convergence review.\n   - **Kill:** no longer relevant, superseded, or too speculative to act on — remove it.\n3. Write the triaged list back to the appropriate tracking file (CLAUDE.md open items section, MEMORY.md, or a project-specific file).\n4. The triage IS the work. Do not treat it as overhead.\n\n### Phase 5: Strategic Evaluation\n\n**Objective:** Assess whether the current trajectory will produce the desired outcome.\n\n1. Review the last 3-4 session summaries or compression logs.\n2. Ask: What was the stated goal at the start of this cycle? What actually happened?\n3. Identify any drift between stated priorities and actual work done.\n4. Produce a one-paragraph trajectory assessment: is the current approach correct, or does direction need adjustment?\n5. Update the convergence ledger with: date, session count consumed, disposition of open items, strategic assessment, and any architectural concerns.\n6. Reset the session counter in the ledger.\n\n### Phase 6: Pre-Deployment Readiness\n\n**Objective:** For any repo approaching a release (tagged version, VPS deploy, Homebrew push), run the full quality gate stack BEFORE the convergence session ends — not as a last-minute afterthought.\n\n1. Identify which repos have pending or imminent releases. Check for:\n   - Unreleased commits ahead of the latest tag: `git log $(git describe --tags --abbrev=0)..HEAD --oneline`\n   - Open PRs targeting release branches\n   - Deploy scripts or provision.sh changes that haven't been tested against the live target\n2. For each release candidate repo, run the **full milestone gate stack** (same layers as `milestone-gate.sh`):\n   - **Go:** `go build .\u002F...` → `go vet .\u002F...` → `golangci-lint run .\u002F...` (if installed) → `go test .\u002F...` → `go test -tags=e2e .\u002F...` (if e2e test files exist)\n   - **TypeScript:** `tsc --noEmit` → `eslint .` (if configured)\n   - **Rust:** `cargo check` → `cargo clippy -- -D warnings` (if installed) → `cargo test`\n   - **Python:** `ruff check .` (if installed) → `pytest` (if configured)\n3. For VPS-bound releases, additionally verify:\n   - `.goreleaser.yaml` builds[].binary name matches provision.sh download URL\n   - `gh release view` on the latest release confirms correct asset names\n   - Environment variables in deploy scripts match what the binary expects (check `.env.example` or config struct)\n4. Record pass\u002Ffail for each gate layer in the convergence ledger. A release candidate that fails ANY gate layer is flagged — it cannot be tagged or deployed until the failure is resolved.\n5. If all gates pass, mark the repo as **release-ready** in the ledger. This is the green light for tagging.\n\nThis phase catches the class of bugs that only surface at release time — missing go:embed directives, stale goreleaser configs, broken e2e flows that unit tests don't cover.\n\n### Phase 7: Deployment Retrospective\n\n**Objective:** Capture friction from any deployments or releases that happened since the last convergence. Deployment friction evaporates fastest because it happens once, at the end, when you're already moving to the next thing.\n\n1. List all deploys, releases, and version tags created since the last convergence date. Check:\n   - `gh release list --repo Org\u002Frepo` for each active repo\n   - `git tag --sort=-creatordate | head -5` for local tags\n   - VPS deploy logs (if accessible): `journalctl -u gateway --since \"last convergence date\"`\n2. For each deployment event, ask three questions:\n   - **What surprised you?** — Any 404s, config mismatches, URL format errors, or permission issues that weren't caught by pre-deploy checks?\n   - **What took longer than expected?** — DNS propagation? Binary naming? Auth token flow? Rate limiting?\n   - **What would catch this earlier?** — A new hook? A pre-deploy checklist item? A seed pattern?\n3. For each surprise or delay:\n   - If it matches an existing seed, update that seed with the new evidence\n   - If it's a new pattern, write a new seed (target: capture 100% of deployment friction, not just coding friction)\n   - If it suggests a mechanical check, note it as a candidate for `milestone-gate.sh` enhancement\n4. Record the retrospective findings in the convergence ledger under a `## Deployment Retro` section.\n\nThe meta-pattern this addresses: coding friction gets captured at ~60% because the debugging loop is tight and seeds are written in-flow. Deployment friction gets captured at ~20% because it happens at session boundaries when you're already wrapping up. This phase closes that gap.\n\n## Output\n\n- Updated `~\u002F.claude\u002Fconvergence-ledger.md` with: date, session count reset, commit sweep results (N commits), validation outcomes, triage decisions (X to next, Y to parking lot, Z killed), strategic assessment, pre-deployment readiness results, and deployment retrospective findings.\n- All repos in a clean or explicitly-documented state.\n- Release candidate repos marked as ready or blocked with specific gate failures.\n- Triaged open items list written back to tracking files.\n- New or updated seeds from deployment retrospective.\n- No new features introduced.\n\n## Examples\n\n**Example 1: YELLOW drift, 12 dirty files, 4 sessions**\n\ndrift-detector fires YELLOW mid-session. Phase 1 inventory finds: 12 dirty files across Gateway and CLI repos, 4 sessions logged. Phase 2 commits 8 files across 3 conventional commits; 4 files blocked by a failing test in `handle_documents_test.go` — documented, left staged. Phase 3 runs deferred `go test .\u002F...` in Gateway; 2 tests fail; root cause logged (nil D1Syncer injection). Phase 4 trots through 11 open items: 4 to next session, 5 to parking lot, 2 killed (superseded by Wave 2C work). Phase 5 assessment: \"Wave 2C RAG track is on schedule but D1Syncer injection is the only remaining blocker — resolve before any other Gateway work.\" Ledger updated, counter reset to 0.\n\n**Example 2: RED drift, manual trigger before a major integration sprint**\n\nUser runs `\u002Fconverge` manually before dispatching 6 parallel agents for Era 4 Phase 1. Phase 1 inventory: 27 dirty files, 6 sessions. Severity RED. Phase 2 commit sweep commits 19 files; 8 held back (incomplete RAG implementation — not shippable). Phase 3 deferred validations: `go build .\u002F...` passes, but `wrangler.toml` has stale Gateway URL (was `localhost:8080`, should be `localhost:7340`) — config bug caught before 6-agent dispatch that would have all failed at the connectivity check. Phase 4: 18 open items triaged. Phase 5 assessment: \"Integration sprint is safe to proceed — all parallel tracks have clean build gates; stale config corrected.\" Ledger reset.\n\n**Example 3: Phase 6 catches a broken embed before release**\n\nGateway has 17 unreleased commits since v3.0.0. Phase 6 runs the full milestone gate. `go build .\u002F...` passes, `go vet` passes, `go test .\u002F...` passes — but `go test -tags=e2e .\u002F...` fails because the Chat SPA static files were not updated after a frontend rebuild. The `go:embed all:chat-ui\u002Fbuild` directive embeds stale build artifacts. Fix: rebuild the SPA (`cd chat-ui && npm run build`) then re-run. Without Phase 6, this would have been caught only after tagging and deploying — a VPS partial-404 (Category 3 from seed_vps_deploy_404_triage).\n\n**Example 4: Phase 7 captures deployment friction that would have evaporated**\n\nDuring the last cycle, gateway@v3.0.0 was released and deployed to a VPS. Phase 7 retrospective asks \"what surprised you?\" — three items surface: (1) `gh release create` needed explicit `--repo DojoGenesis\u002Fgateway` flag because auth user was TresPies-source, (2) provision.sh had the wrong tarball name (repo name vs binary name mismatch), (3) Cloudflare DNS API token was created ad-hoc and almost not saved to Infisical. Items 1 and 2 already exist as seeds; their evidence sections are updated. Item 3 is written as a new seed (seed_vps_secrets_bootstrap). Without Phase 7, these three friction points would have been lost — they happened at session end when the operator was already moving on.\n\n## Edge Cases\n\n- If the convergence ledger does not exist at `~\u002F.claude\u002Fconvergence-ledger.md`, create it with today's date as the baseline entry before running any phases.\n- If a commit sweep produces a pre-commit hook failure, fix the hook violation and retry — do not use `--no-verify`. The failed commit still counts as a deferred validation; log it.\n- If Phase 5 strategic evaluation reveals the current trajectory is fundamentally wrong (not just drifted), escalate: stop the convergence session, surface the misalignment explicitly, and do not resume feature work until the strategic question is resolved.\n- If drift is RED and the repo is a sub-repo with its own `.git`, treat it as an independent convergence unit — commit sweeps and validations run inside that repo's context, not the parent monorepo.\n\n## Anti-Patterns\n\n- **\"Just one quick fix while I'm here\"** — Convergence is not a feature session. Any discovered fix is logged and deferred. Implementing it during convergence defeats the purpose: you add new state while trying to settle existing state.\n- **Skipping Phase 4 triage because \"it's not code work\"** — The open items triage is the highest-leverage work in the entire session. Deferred decisions compound faster than deferred code.\n- **Treating convergence as optional when things are going well** — Drift is invisible until it is expensive. YELLOW is the time to converge, not when you hit RED with a broken build the day before a deadline.\n- **Force-committing broken state to clear the dirty file count** — A clean `git status` achieved by committing broken code is not convergence; it is disguised debt. Document the blocker; leave the files unstaged.\n- **Running convergence in the middle of a half-finished feature** — Convergence should happen at natural session boundaries. If you are mid-task, finish the task (or stage the work-in-progress explicitly), then converge.\n- **Tagging a release without running Phase 6** — The milestone-gate.sh hook catches this mechanically at `git tag` time, but if you bypass the hook (CI\u002FCD, manual tag), Phase 6 is the last line of defense. A tag without a full gate pass is not a release — it's a gamble.\n- **Skipping Phase 7 because \"the deploy went fine\"** — The deploys that \"went fine\" still had friction: DNS propagation delays, permission fumbles, config copy-paste. If you don't capture it within one convergence cycle, it's gone. Deployment friction has a 20% natural capture rate vs 60% for coding friction — Phase 7 closes the gap.\n- **Running Phase 6 only on the repo you're about to release** — Check ALL repos with unreleased commits, not just the one you intend to tag. Other repos may have accumulated shippable state that should be released in the same cycle rather than drifting further.\n","# Convergence Gate Skill\n\n## Philosophy\n\nSonnet sessions produce excellent artifacts but poor trajectory. Each session is locally optimal — clean build, tests pass, seed captured — but globally drifting: more open items, more uncommitted state, more deferred validation. The missing discipline is periodic evaluation of trajectory, not just output.\n\nConvergence is not a feature session. It produces no new features. It produces a clean, tested, committed, evaluated state — and a reset counter so the next cycle starts from solid ground.\n\nThe drift-detector.sh hook enforces this mechanically, but the convergence gate skill is the procedure that actually runs when the hook fires.\n\nConvergence also enforces two deployment disciplines: a **pre-deployment readiness check** that forces full build\u002Flint\u002Ftest\u002Fe2e verification before any release, and a **deployment retrospective** that captures friction from recent deploys before it evaporates.\n\n## When to Use\n\n- When `drift-detector.sh` fires a **YELLOW warning** (10+ dirty files OR 4+ sessions since last convergence)\n- When `drift-detector.sh` fires a **RED warning** (25+ dirty files OR 6+ sessions)\n- When open-items lists have been growing across multiple sessions without resolution\n- When multiple deferred validations (tests, build checks, config audits) have accumulated\n- When you sense \"things are going well\" but can't clearly articulate what the next priority is — that ambiguity is exactly what convergence resolves\n\nDo not use this skill for feature work. Convergence sessions produce zero new features. Any fix discovered during convergence is logged and deferred — never implemented in-session.\n\n## Workflow\n\n### Phase 1: Inventory\n\n**Objective:** Establish a complete picture of the current state before touching anything.\n\n1. Run `git status` across all active repos to count dirty files and identify untracked paths.\n2. Read `~\u002F.claude\u002Fconvergence-ledger.md` to confirm session count since last convergence.\n3. Identify the drift severity: YELLOW (10+ files or 4+ sessions) or RED (25+ files or 6+ sessions).\n4. List all open items from CLAUDE.md, MEMORY.md, and any active TODO files — do not edit them yet.\n5. Identify deferred validations: any `go build`, `go test`, migration checks, or connectivity tests that were skipped in prior sessions.\n\nOutput of Phase 1: a flat inventory list. No judgments or actions yet.\n\n### Phase 2: Commit Sweep\n\n**Objective:** Commit all work-in-progress that is ready to ship.\n\n1. For each dirty repo, determine if the changes are shippable (build passes, tests pass, intent clear).\n2. Run `go build .\u002F...` and `go test .\u002F...` before staging any Go files.\n3. Commit shippable changes with conventional commit messages (`feat:`, `fix:`, `chore:`, `docs:`).\n4. For changes that are NOT shippable, document the blocker in the convergence ledger and leave them staged or unstaged — do not force-commit broken state.\n5. After all commits land, confirm `git status` is clean (or explains each remaining dirty file).\n\n### Phase 3: Deferred Validations\n\n**Objective:** Run every validation that was skipped or deferred in previous sessions.\n\n1. Execute each deferred check from the Phase 1 inventory.\n2. For each validation:\n   - **Pass:** note it in the ledger and close the deferred item.\n   - **Fail:** document the failure, its probable root cause, and the specific fix needed — but do NOT implement the fix in this session.\n3. Config checks take priority: scan `settings.json`, `.env`, `wrangler.toml`, and any gateway config for stale URLs or missing keys before debugging any code.\n4. MCP server connectivity: verify each configured server responds before reporting any MCP tool as broken.\n\n### Phase 4: Open Items Triage\n\n**Objective:** Decide the fate of every open item — resolve, defer, or kill.\n\n1. Read through the accumulated open items list from Phase 1.\n2. For each item, assign one of three dispositions:\n   - **Next session:** high priority, unblocked, clear definition of done.\n   - **Parking lot:** valid but not urgent; survives to next convergence review.\n   - **Kill:** no longer relevant, superseded, or too speculative to act on — remove it.\n3. Write the triaged list back to the appropriate tracking file (CLAUDE.md open items section, MEMORY.md, or a project-specific file).\n4. The triage IS the work. Do not treat it as overhead.\n\n### Phase 5: Strategic Evaluation\n\n**Objective:** Assess whether the current trajectory will produce the desired outcome.\n\n1. Review the last 3-4 session summaries or compression logs.\n2. Ask: What was the stated goal at the start of this cycle? What actually happened?\n3. Identify any drift between stated priorities and actual work done.\n4. Produce a one-paragraph trajectory assessment: is the current approach correct, or does direction need adjustment?\n5. Update the convergence ledger with: date, session count consumed, disposition of open items, strategic assessment, and any architectural concerns.\n6. Reset the session counter in the ledger.\n\n### Phase 6: Pre-Deployment Readiness\n\n**Objective:** For any repo approaching a release (tagged version, VPS deploy, Homebrew push), run the full quality gate stack BEFORE the convergence session ends — not as a last-minute afterthought.\n\n1. Identify which repos have pending or imminent releases. Check for:\n   - Unreleased commits ahead of the latest tag: `git log $(git describe --tags --abbrev=0)..HEAD --oneline`\n   - Open PRs targeting release branches\n   - Deploy scripts or provision.sh changes that haven't been tested against the live target\n2. For each release candidate repo, run the **full milestone gate stack** (same layers as `milestone-gate.sh`):\n   - **Go:** `go build .\u002F...` → `go vet .\u002F...` → `golangci-lint run .\u002F...` (if installed) → `go test .\u002F...` → `go test -tags=e2e .\u002F...` (if e2e test files exist)\n   - **TypeScript:** `tsc --noEmit` → `eslint .` (if configured)\n   - **Rust:** `cargo check` → `cargo clippy -- -D warnings` (if installed) → `cargo test`\n   - **Python:** `ruff check .` (if installed) → `pytest` (if configured)\n3. For VPS-bound releases, additionally verify:\n   - `.goreleaser.yaml` builds[].binary name matches provision.sh download URL\n   - `gh release view` on the latest release confirms correct asset names\n   - Environment variables in deploy scripts match what the binary expects (check `.env.example` or config struct)\n4. Record pass\u002Ffail for each gate layer in the convergence ledger. A release candidate that fails ANY gate layer is flagged — it cannot be tagged or deployed until the failure is resolved.\n5. If all gates pass, mark the repo as **release-ready** in the ledger. This is the green light for tagging.\n\nThis phase catches the class of bugs that only surface at release time — missing go:embed directives, stale goreleaser configs, broken e2e flows that unit tests don't cover.\n\n### Phase 7: Deployment Retrospective\n\n**Objective:** Capture friction from any deployments or releases that happened since the last convergence. Deployment friction evaporates fastest because it happens once, at the end, when you're already moving to the next thing.\n\n1. List all deploys, releases, and version tags created since the last convergence date. Check:\n   - `gh release list --repo Org\u002Frepo` for each active repo\n   - `git tag --sort=-creatordate | head -5` for local tags\n   - VPS deploy logs (if accessible): `journalctl -u gateway --since \"last convergence date\"`\n2. For each deployment event, ask three questions:\n   - **What surprised you?** — Any 404s, config mismatches, URL format errors, or permission issues that weren't caught by pre-deploy checks?\n   - **What took longer than expected?** — DNS propagation? Binary naming? Auth token flow? Rate limiting?\n   - **What would catch this earlier?** — A new hook? A pre-deploy checklist item? A seed pattern?\n3. For each surprise or delay:\n   - If it matches an existing seed, update that seed with the new evidence\n   - If it's a new pattern, write a new seed (target: capture 100% of deployment friction, not just coding friction)\n   - If it suggests a mechanical check, note it as a candidate for `milestone-gate.sh` enhancement\n4. Record the retrospective findings in the convergence ledger under a `## Deployment Retro` section.\n\nThe meta-pattern this addresses: coding friction gets captured at ~60% because the debugging loop is tight and seeds are written in-flow. Deployment friction gets captured at ~20% because it happens at session boundaries when you're already wrapping up. This phase closes that gap.\n\n## Output\n\n- Updated `~\u002F.claude\u002Fconvergence-ledger.md` with: date, session count reset, commit sweep results (N commits), validation outcomes, triage decisions (X to next, Y to parking lot, Z killed), strategic assessment, pre-deployment readiness results, and deployment retrospective findings.\n- All repos in a clean or explicitly-documented state.\n- Release candidate repos marked as ready or blocked with specific gate failures.\n- Triaged open items list written back to tracking files.\n- New or updated seeds from deployment retrospective.\n- No new features introduced.\n\n## Examples\n\n**Example 1: YELLOW drift, 12 dirty files, 4 sessions**\n\ndrift-detector fires YELLOW mid-session. Phase 1 inventory finds: 12 dirty files across Gateway and CLI repos, 4 sessions logged. Phase 2 commits 8 files across 3 conventional commits; 4 files blocked by a failing test in `handle_documents_test.go` — documented, left staged. Phase 3 runs deferred `go test .\u002F...` in Gateway; 2 tests fail; root cause logged (nil D1Syncer injection). Phase 4 trots through 11 open items: 4 to next session, 5 to parking lot, 2 killed (superseded by Wave 2C work). Phase 5 assessment: \"Wave 2C RAG track is on schedule but D1Syncer injection is the only remaining blocker — resolve before any other Gateway work.\" Ledger updated, counter reset to 0.\n\n**Example 2: RED drift, manual trigger before a major integration sprint**\n\nUser runs `\u002Fconverge` manually before dispatching 6 parallel agents for Era 4 Phase 1. Phase 1 inventory: 27 dirty files, 6 sessions. Severity RED. Phase 2 commit sweep commits 19 files; 8 held back (incomplete RAG implementation — not shippable). Phase 3 deferred validations: `go build .\u002F...` passes, but `wrangler.toml` has stale Gateway URL (was `localhost:8080`, should be `localhost:7340`) — config bug caught before 6-agent dispatch that would have all failed at the connectivity check. Phase 4: 18 open items triaged. Phase 5 assessment: \"Integration sprint is safe to proceed — all parallel tracks have clean build gates; stale config corrected.\" Ledger reset.\n\n**Example 3: Phase 6 catches a broken embed before release**\n\nGateway has 17 unreleased commits since v3.0.0. Phase 6 runs the full milestone gate. `go build .\u002F...` passes, `go vet` passes, `go test .\u002F...` passes — but `go test -tags=e2e .\u002F...` fails because the Chat SPA static files were not updated after a frontend rebuild. The `go:embed all:chat-ui\u002Fbuild` directive embeds stale build artifacts. Fix: rebuild the SPA (`cd chat-ui && npm run build`) then re-run. Without Phase 6, this would have been caught only after tagging and deploying — a VPS partial-404 (Category 3 from seed_vps_deploy_404_triage).\n\n**Example 4: Phase 7 captures deployment friction that would have evaporated**\n\nDuring the last cycle, gateway@v3.0.0 was released and deployed to a VPS. Phase 7 retrospective asks \"what surprised you?\" — three items surface: (1) `gh release create` needed explicit `--repo DojoGenesis\u002Fgateway` flag because auth user was TresPies-source, (2) provision.sh had the wrong tarball name (repo name vs binary name mismatch), (3) Cloudflare DNS API token was created ad-hoc and almost not saved to Infisical. Items 1 and 2 already exist as seeds; their evidence sections are updated. Item 3 is written as a new seed (seed_vps_secrets_bootstrap). Without Phase 7, these three friction points would have been lost — they happened at session end when the operator was already moving on.\n\n## Edge Cases\n\n- If the convergence ledger does not exist at `~\u002F.claude\u002Fconvergence-ledger.md`, create it with today's date as the baseline entry before running any phases.\n- If a commit sweep produces a pre-commit hook failure, fix the hook violation and retry — do not use `--no-verify`. The failed commit still counts as a deferred validation; log it.\n- If Phase 5 strategic evaluation reveals the current trajectory is fundamentally wrong (not just drifted), escalate: stop the convergence session, surface the misalignment explicitly, and do not resume feature work until the strategic question is resolved.\n- If drift is RED and the repo is a sub-repo with its own `.git`, treat it as an independent convergence unit — commit sweeps and validations run inside that repo's context, not the parent monorepo.\n\n## Anti-Patterns\n\n- **\"Just one quick fix while I'm here\"** — Convergence is not a feature session. Any discovered fix is logged and deferred. Implementing it during convergence defeats the purpose: you add new state while trying to settle existing state.\n- **Skipping Phase 4 triage because \"it's not code work\"** — The open items triage is the highest-leverage work in the entire session. Deferred decisions compound faster than deferred code.\n- **Treating convergence as optional when things are going well** — Drift is invisible until it is expensive. YELLOW is the time to converge, not when you hit RED with a broken build the day before a deadline.\n- **Force-committing broken state to clear the dirty file count** — A clean `git status` achieved by committing broken code is not convergence; it is disguised debt. Document the blocker; leave the files unstaged.\n- **Running convergence in the middle of a half-finished feature** — Convergence should happen at natural session boundaries. If you are mid-task, finish the task (or stage the work-in-progress explicitly), then converge.\n- **Tagging a release without running Phase 6** — The milestone-gate.sh hook catches this mechanically at `git tag` time, but if you bypass the hook (CI\u002FCD, manual tag), Phase 6 is the last line of defense. A tag without a full gate pass is not a release — it's a gamble.\n- **Skipping Phase 7 because \"the deploy went fine\"** — The deploys that \"went fine\" still had friction: DNS propagation delays, permission fumbles, config copy-paste. If you don't capture it within one convergence cycle, it's gone. Deployment friction has a 20% natural capture rate vs 60% for coding friction — Phase 7 closes the gap.\n- **Running Phase 6 only on the repo you're about to release** — Check ALL repos with unreleased commits, not just the one you intend to tag. Other repos may have accumulated shippable state that should be released in the same cycle rather than drifting further.\n",{"name":5,"tags":49,"tier":52,"model":29,"agents":53,"inputs":55,"outputs":60,"version":65,"category":66,"triggers":67,"description":7,"tool_dependencies":72},[25,37,50,51],"hygiene","governance",1,[54],"primary",[56],{"name":57,"type":58,"required":45,"description":59},"trigger_reason","string","Why convergence is being run — YELLOW drift warning, RED drift warning, or manual call",[61],{"name":62,"type":63,"format":39,"description":64},"convergence_report","ref","Updated convergence ledger entry with session count reset, commit sweep results, triage decisions, and strategic evaluation","1.1.0","system-health",[68,69,70,71,24],"drift detector fires RED","drift detector fires YELLOW","run convergence session","arrest strategic drift",[73],"file_system","main","ff07df5fd8f75762c2a131e6e26d297e8ae403ee","plugins\u002Fsystem-health\u002Fskills\u002Fconvergence-gate",0,"https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway","https:\u002F\u002Fgithub.com\u002FDojoGenesis","dojogenesis.com","2026-10-25 22:59:58",{"source":8,"skillName":5,"commands":83,"prompt":93,"zipAvailable":94},[84,87,90],{"tool":85,"command":86},"npx","npx skills add DojoGenesis\u002Fgateway --skill convergence-gate",{"tool":88,"command":89},"bunx","bunx skills add DojoGenesis\u002Fgateway --skill convergence-gate",{"tool":91,"command":92},"pnpm","pnpm dlx skills add DojoGenesis\u002Fgateway --skill convergence-gate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fsystem-health\u002Fskills\u002Fconvergence-gate\u002FSKILL.md",true,[],[97,116,127,135,175,199],{"skillNo":98,"name":99,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":105,"publishedAt":44},"01M6P6J0WYSD1MTGA3ZX6MGGZ5","kata-test-echo","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-test-echo\u002FSKILL.md",[102],{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[106,107,108,109,110,111,112,113,114,115],"kata test echo","Echo","test","json","v1","output","input","structured","contracts","schema",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":123,"publishedAt":44},"01M6P6HQJNGG4WPZW0DEWMAY2N","kata-plain","An ordinary prose skill; not dispatchable.","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-plain\u002FSKILL.md",[122],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[124,125,126],"kata plain","prose skill","prose",{"skillNo":128,"name":129,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":44},"01M6P6HH6Y7K8K6606MF7VZ1HB","kata-broken","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-broken\u002FSKILL.md",[],[133,134,113,114,107,115,109,108,112,110,111],"kata broken","broken",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":155,"publishedAt":44},"01M6P6GW520QJ03A6K7Y5PWJ52","voice-before-structure","Read the project's design language and philosophy before writing structural artifacts. Ground manifests, READMEs, and descriptions in the project's voice, not boilerplate. Use when creating manifests or READMEs for established projects, writing ecosystem-level documentation, building plugin descriptions or marketplace metadata, or authoring metadata that carries a project's identity. Trigger phrases: 'write the manifest', 'create a README', 'describe this plugin', 'ground yourself in the philosophy', 'ecosystem-level work'.","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fvoice-before-structure\u002FSKILL.md",[141,144,147,152],{"categoryNo":142,"categoryName":143,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":145,"categoryName":146,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":153,"categoryName":154,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000036","内容创作者",[156,157,158,159,160,34,161,162,163,164,165,166,167,168,169,170,171,172,173,174],"voice before structure","structure","voice","manifests","ecosystem","authoring","structural","project","artifact","philosophy","design","writing","identity","documentation","create","projects","work","read","write",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":182,"publishedAt":44},"01M6P6GMNA4HJ4D5RRM3BQZ73M","system-prompt-archaeology","Produces a named ADA disposition preset (YAML) and a layered behavioral analysis (structural decomposition + evidence-cited classifications) from a system prompt. Use when: \"analyze this system prompt\", \"extract disposition from prompt\", \"reverse-engineer agent behavior\", \"what patterns does this prompt use\", \"build a preset from this prompt\".","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fsystem-prompt-archaeology\u002FSKILL.md",[181],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[183,184,185,38,186,187,162,188,189,190,191,192,193,194,195,196,33,30,197,198],"system prompt archaeology","system prompt","prompt","behavioral","classify","decomposition","wisdom","patterns","engineer","decompose","evidence","ada","analyze","analysis","true","reverse",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":206,"publishedAt":44},"01M6P6G2D70T9R00HX6K154X5Y","session-lifecycle-automation","Designs and configures all three loops of solo-operator session automation — session bookends, background maintenance agents, and a delegation flywheel. Use when setting up a new workspace, recovering from the 44% zero-artifact session leak, or preparing to scale delegation across multiple concurrent agents.","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fsession-lifecycle-automation\u002FSKILL.md",[205],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[207,208,209,210,211,39,212,213,214,215,216,217,218,164,219,220,221,222,223,224],"automation","session lifecycle automation","session lifecycle","lifecycle","session","configure","directory","config","delegation","audit","SET","files","solo","across","scheduled","loops","up","template"]