@codragraph/cli 1.6.4 → 2.1.0

package/skills/codragraph-gh-pr-workflow.md

@@ -0,0 +1,176 @@
+---
+name: codragraph-gh-pr-workflow
+description: "Use for any pull-request workflow via GitHub CLI — create draft, convert ready, request review, address comments, check CI, merge with the right strategy, manage stacked PRs. Examples: \"open a PR\", \"draft PR\", \"merge this PR\", \"check PR status\", \"address review comments\", \"stacked PRs\""
+---
+
+# Pull Request Workflow with `gh`
+
+## When to Use
+
+- "Open a PR for this branch."
+- "Convert this draft to ready-for-review."
+- "Check the status of my PRs."
+- "Merge PR #N — which strategy should I use?"
+- "Address review comments and push fixes."
+- "I have stacked PRs — how do I manage them?"
+
+## Lifecycle commands
+
+### Open
+
+```bash
+# After pushing your branch:
+gh pr create --title "feat: …" --body "…" --reviewer @teammate
+gh pr create --draft                              # ship as draft
+gh pr create --fill                               # use the most recent commit message
+gh pr create --base main --head my-branch         # explicit base/head
+
+# Multi-line body (HEREDOC) — preferred for real PRs:
+gh pr create --title "feat: X" --body "$(cat <<'EOF'
+## Summary
+- Bullet 1
+- Bullet 2
+
+## Test plan
+- [ ] Unit
+- [ ] Integration
+- [ ] Manual repro of the bug
+EOF
+)"
+```
+
+### Inspect
+
+```bash
+gh pr list                                        # PRs in this repo (yours by default)
+gh pr list --state all --author "@me"             # all your PRs ever
+gh pr status                                      # PRs needing attention (created by you, requesting your review)
+gh pr view <N>                                    # one PR's metadata
+gh pr view <N> --comments                         # include review comments
+gh pr diff <N>                                    # raw diff
+gh pr checks <N>                                  # CI status per check
+```
+
+### Update
+
+```bash
+# Push fixes to the same branch:
+git push                                          # PR auto-updates
+
+# Convert draft <-> ready:
+gh pr ready <N>                                   # draft → ready-for-review
+gh pr ready --undo <N>                            # ready → draft
+
+# Edit metadata:
+gh pr edit <N> --title "…" --add-reviewer @teammate --add-label "bug"
+```
+
+### Address review comments
+
+```bash
+# Pull the conversation:
+gh pr view <N> --comments
+
+# Push your fixes (same branch):
+git add <files> && git commit -m "address review: <topic>"
+git push
+
+# Mark conversations resolved (UI only, no CLI flag) or reply:
+gh pr comment <N> --body "fixed in <new-sha>"
+```
+
+### Merge
+
+| Strategy | When | gh command |
+|---|---|---|
+| **Squash** | One logical change, want one commit on main | `gh pr merge <N> --squash --delete-branch` |
+| **Rebase** | Multiple already-tidy commits, no merge bubble | `gh pr merge <N> --rebase --delete-branch` |
+| **Merge commit** | Long-running release branch, preserve topology | `gh pr merge <N> --merge --delete-branch` |
+| **Auto-merge** | Merge as soon as CI green + reviews approved | `gh pr merge <N> --auto --squash --delete-branch` |
+
+See `codragraph-git-rebase-vs-merge` for the decision rule. Default to
+**squash** for typical feature PRs.
+
+### Close / reopen
+
+```bash
+gh pr close <N> --comment "superseded by #<other>"
+gh pr reopen <N>
+```
+
+## Stacked PR pattern (`gh pr` with branches that depend on each other)
+
+When PR #2 depends on PR #1's branch, point #2's base at #1's branch:
+
+```bash
+git switch feat/step-1
+gh pr create --base main --title "feat: step 1"
+
+git switch -c feat/step-2 feat/step-1
+# … edit …
+git push -u origin feat/step-2
+gh pr create --base feat/step-1 --title "feat: step 2 (depends on #N)"
+
+# When step-1 merges, automatically retarget step-2 to main:
+gh pr edit <step-2-pr> --base main
+```
+
+## Why CodraGraph helps here
+
+The PR review GitHub Action (codragraph-pr-review) ALREADY automates the
+diff-comment side. As an author, you should ALSO run impact locally
+before requesting review — it catches the "I forgot to update a caller"
+class of problem that a reviewer is most likely to flag:
+
+```bash
+codragraph_detect_changes({scope: "compare", base_ref: "main"})
+# → list of changed symbols + affected execution flows
+
+# For each non-trivial changed symbol:
+codragraph_impact({target: "<symbol>", direction: "upstream"})
+# → d=1 callers. Are they all updated in the PR?
+```
+
+If d=1 callers exist OUTSIDE your PR diff, that's the breakage waiting
+to happen. Either update them or document the migration path before
+review.
+
+## Author checklist before requesting review
+
+```
+- [ ] Branch rebased onto main (or merged main in, if shared)
+- [ ] CI green: gh pr checks <N>
+- [ ] codragraph_detect_changes — confirm scope is what you intended
+- [ ] codragraph_impact on each public symbol you changed — d=1 callers updated
+- [ ] PR title is conventional (feat: / fix: / docs: / etc.)
+- [ ] PR body has Summary + Test plan
+- [ ] Reviewers and labels set
+- [ ] gh pr ready <N> if it was draft
+```
+
+## Reviewer checklist (if you're reviewing)
+
+```
+- [ ] Pull the diff: gh pr diff <N> | less
+- [ ] Use codragraph-pr-review skill: detect_changes + impact + context
+- [ ] Run tests locally: gh pr checkout <N> && npm test
+- [ ] Approve / request-changes / comment via gh pr review <N>
+```
+
+```bash
+gh pr review <N> --approve --body "LGTM. Verified the impact graph clean."
+gh pr review <N> --request-changes --body "…"
+gh pr review <N> --comment --body "…"
+
+# Inline comments require the GitHub UI (gh CLI doesn't support them yet).
+```
+
+## Pitfalls
+
+| Pitfall | Symptom | Fix |
+|---|---|---|
+| Created PR from main | "There isn't anything to compare" | Push to a feature branch first |
+| Wrong base | PR shows commits from main | `gh pr edit <N> --base <correct-base>` |
+| Squash-merged a stacked PR's parent | Child PR shows 0 commits | `git rebase main` on child, force-push |
+| `gh pr merge --auto` without branch protection | Merges immediately, not on green | Configure branch-protection rules first |
+| Closing instead of merging | Commits don't land on main | `gh pr merge` not `gh pr close` |

package/skills/codragraph-gh-release-workflow.md

@@ -0,0 +1,187 @@
+---
+name: codragraph-gh-release-workflow
+description: "Use for the release workflow — semver bump, tag, generate release notes, attach assets, draft vs published, prerelease tagging, and propagating to npm. Examples: \"cut a release\", \"create a GitHub release\", \"draft release notes\", \"upload binaries to release\", \"prerelease v2 alpha\""
+---
+
+# Release Workflow with `gh`
+
+## When to Use
+
+- "Cut a 1.7.0 release."
+- "Draft release notes from commits."
+- "Attach the built binaries to the release."
+- "Mark this as a prerelease (alpha / beta / RC)."
+- "Re-publish notes after I edited them."
+
+## Pre-release checklist (do these BEFORE `gh release create`)
+
+```
+- [ ] Branch is main / release/x.y, fully synced
+- [ ] CHANGELOG.md updated (or ready to be auto-generated)
+- [ ] Version bumped in package.json / Cargo.toml / pyproject.toml
+- [ ] All commits since last tag intentional (no leftover wip)
+- [ ] CI green on the release commit (gh pr checks <N>)
+- [ ] codragraph diff <last-tag> HEAD --semantic — review removed APIs
+      (any removed public API = SemVer major; document loudly in notes)
+```
+
+## Cutting the release
+
+```bash
+# 1. Bump + commit version
+npm version 1.7.0 --no-git-tag-version            # or pnpm version, or manual edit
+git add package.json package-lock.json
+git commit -m "chore(release): 1.7.0"
+git push origin main
+
+# 2. Tag (annotated, signed if you have GPG):
+git tag -a v1.7.0 -m "Release 1.7.0"              # annotated
+git tag -s v1.7.0 -m "Release 1.7.0"              # signed (requires GPG setup)
+git push origin v1.7.0
+
+# 3. Create GitHub release. Auto-generate notes from commits since the previous tag:
+gh release create v1.7.0 --generate-notes
+```
+
+`--generate-notes` uses `.github/release.yml` (if present) for category
+filtering, or falls back to a flat list of commit titles.
+
+## Custom notes
+
+```bash
+# Notes from a file:
+gh release create v1.7.0 --notes-file RELEASE_NOTES.md
+
+# Inline (HEREDOC, the right way):
+gh release create v1.7.0 --notes "$(cat <<'EOF'
+## What's new
+- npx zero-install entry — no more 3-step setup
+- PR review GitHub Action (deterministic + LLM modes)
+- 17 built-in workflow skills
+
+## Breaking
+- None.
+
+## Upgrade
+\`\`\`
+npm i -g @codragraph/cli@1.7.0
+\`\`\`
+EOF
+)"
+
+# Edit notes after publishing:
+gh release edit v1.7.0 --notes-file new-notes.md
+```
+
+## Attach assets
+
+```bash
+# After creating the release, upload binaries / source bundles:
+gh release upload v1.7.0 dist/cli-linux-x64.tar.gz dist/cli-darwin-arm64.tar.gz
+
+# Or in one shot at create time:
+gh release create v1.7.0 dist/*.tar.gz dist/*.zip --generate-notes
+```
+
+## Draft vs published vs prerelease
+
+```bash
+# Draft (visible only to maintainers, not yet announced):
+gh release create v1.7.0 --draft --generate-notes
+
+# Promote draft → published:
+gh release edit v1.7.0 --draft=false
+
+# Prerelease (alpha / beta / RC — semver string ends with -alpha.N etc.):
+gh release create v2.0.0-alpha.1 --prerelease --generate-notes
+
+# Mark an existing release as latest (otherwise GitHub picks by semver):
+gh release edit v1.7.0 --latest
+```
+
+## Re-publish a release after editing
+
+```bash
+# View existing release:
+gh release view v1.7.0
+
+# Edit notes:
+gh release edit v1.7.0 --notes-file fixed-notes.md
+
+# Upload missing asset:
+gh release upload v1.7.0 dist/cli-windows-x64.zip
+```
+
+## Coordinating with npm publish
+
+For a TypeScript / Node package, the GitHub release and the npm publish
+are TWO separate events:
+
+```bash
+# Order: tag → npm publish → GH release (so the release links a version
+# users can `npm install`).
+
+git tag v1.7.0 && git push origin v1.7.0
+npm publish --access public                       # for scoped packages
+gh release create v1.7.0 --generate-notes
+```
+
+You can automate this in a workflow that triggers on `push` of a `v*` tag:
+
+```yaml
+on:
+  push:
+    tags: ['v*']
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          registry-url: 'https://registry.npmjs.org'
+      - run: npm ci && npm run build
+      - run: npm publish --access public
+        env:
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
+      - uses: softprops/action-gh-release@v2
+        with:
+          generate_release_notes: true
+```
+
+## Why CodraGraph helps here
+
+The structural diff between two tags is the most honest changelog you'll
+ever produce — it's derived from the graph, not from commit messages
+that lie:
+
+```bash
+codragraph diff v1.6.4 v1.7.0 --semantic --json > /tmp/diff.json
+
+# What changed:
+jq '.semantic.addedAPIs | length, .semantic.removedAPIs | length, .semantic.classifiedModifications | length' /tmp/diff.json
+
+# Generate a structured "API changes" section for the release notes:
+jq -r '
+  "### Added APIs\n" +
+  ([.semantic.addedAPIs[] | "- `" + (.name // .id) + "`"] | join("\n")) +
+  "\n\n### Removed APIs (BREAKING)\n" +
+  ([.semantic.removedAPIs[] | "- `" + (.name // .id) + "`"] | join("\n"))
+' /tmp/diff.json
+```
+
+Removed APIs = SemVer major. Modified signatures with parameter-count
+changes = SemVer major. Use this to keep your bump honest.
+
+## Pitfalls
+
+| Pitfall | Symptom | Fix |
+|---|---|---|
+| Forgot to push the tag | GH release creation fails | `git push origin v1.7.0` |
+| `npm publish` before the tag | Tag not on the published commit | publish AFTER pushing the tag |
+| Removed an API but bumped only minor | Breaking change in non-major release | Always run `codragraph diff <prev> HEAD --semantic` and bump major if removedAPIs is non-empty |
+| `--generate-notes` produces noise | All commit messages flat-listed | Add `.github/release.yml` to categorize by labels / paths |
+| Wrong release marked `latest` | Older release stays as latest | `gh release edit <new-version> --latest` |
+| Released a prerelease as stable | Users on `latest` channel get unstable code | Always `--prerelease` for alpha / beta / RC |
+```

package/skills/codragraph-git-bisect.md

@@ -0,0 +1,176 @@
+---
+name: codragraph-git-bisect
+description: "Use when hunting a regression — narrowing down which commit introduced a bug across N commits using binary search. Covers manual bisect, automated bisect with a test script, and how to combine bisect with CodraGraph context to understand the bad commit. Examples: \"find which commit broke X\", \"git bisect\", \"regression hunt\", \"automated bisect\""
+---
+
+# Regression Hunting with `git bisect`
+
+## When to Use
+
+- "Tests pass at commit A but fail at commit B — which commit broke it?"
+- "Performance regressed somewhere in the last 200 commits."
+- "Find the commit that introduced this bug."
+- "Automate a bisect with my test suite."
+
+## The principle
+
+Bisect performs binary search over the commit graph. Given a
+known-good commit (`good`) and a known-bad commit (`bad`), it picks the
+midpoint, you mark it, and it halves the search space until exactly one
+commit is identified. Log₂(N) tests instead of N.
+
+## Manual workflow
+
+```bash
+# Start
+git bisect start
+git bisect bad <known-bad>            # often HEAD or a commit/tag
+git bisect good <known-good>          # something older that worked
+
+# Now git checks out the midpoint. Test it.
+# Mark each midpoint:
+git bisect bad                        # if the bug IS present
+git bisect good                       # if the bug is NOT present
+git bisect skip                       # if the commit can't be tested
+                                      # (won't compile, broken in some other way)
+
+# Bisect narrows down. Repeat marking until git announces:
+# → "<sha> is the first bad commit"
+
+# Done — back to your starting state:
+git bisect reset
+```
+
+## Automated workflow
+
+If you have a script that exits 0 on good and non-zero on bad, you can
+fully automate:
+
+```bash
+git bisect start HEAD <known-good>
+git bisect run ./scripts/repro-bug.sh
+# → bisect runs the script at each midpoint; marks good/bad automatically;
+#   announces the first bad commit when done
+```
+
+The script's exit codes:
+
+```
+exit 0          → mark as good
+exit 1..124,    → mark as bad
+   126..127
+exit 125        → mark as skip (can't test this commit)
+exit 128+       → abort the bisect
+```
+
+## Test-script template
+
+```bash
+#!/usr/bin/env bash
+# scripts/repro-bug.sh — bisect-aware reproduction script
+set -e
+
+# 1. If this commit can't even build, skip it (don't say bad).
+npm install --silent --no-audit > /dev/null 2>&1 || exit 125
+npm run build > /dev/null 2>&1 || exit 125
+
+# 2. Run the targeted test that demonstrates the bug.
+if npx vitest run path/to/regression.test.ts --reporter=basic > /dev/null 2>&1; then
+  exit 0    # good
+else
+  exit 1    # bad
+fi
+```
+
+## Why CodraGraph helps here
+
+Once bisect names the first bad commit, the next question is *why*
+that commit broke things. CodraGraph's `diff --semantic` and `context`
+tell you exactly what changed, structurally:
+
+```bash
+git bisect log                            # see the bisection that found it
+BAD=$(git bisect log | grep "first bad commit" | awk '{print $1}')
+
+# What changed structurally between good and bad?
+codragraph diff "$BAD"^ "$BAD" --semantic
+# → addedAPIs / removedAPIs / classifiedModifications
+
+# Get full context on the modified symbols
+codragraph_context({name: "<symbol from the diff>"})
+```
+
+This turns "commit X is bad" into "commit X removed/modified Y, which
+broke flow Z." That's the actionable answer.
+
+## Bisect across non-linear history
+
+If your history has merges, bisect handles them but the midpoints are
+weird (commits from sibling branches). Two helpful flags:
+
+```bash
+git bisect start --first-parent HEAD <known-good>
+# → only follows the first-parent path (main line of merges).
+#   Useful when feature-branch commits aren't worth testing individually.
+
+git bisect start --no-checkout HEAD <known-good>
+# → don't checkout each midpoint; instead just sets BISECT_HEAD ref.
+#   Use when checkout is expensive (huge repo, slow build).
+```
+
+## Pitfalls
+
+| Pitfall | What happens | Fix |
+|---|---|---|
+| Forgot to `bisect reset` after finishing | Stuck in detached state, future `git pull` weird | `git bisect reset` returns you to your branch |
+| Test depends on uncommitted state | Bisect finds noise, not the real bug | Stash before bisecting; ensure script is self-contained |
+| Build broken in middle of range | Every middle commit looks "bad" | Use `git bisect skip` or exit-code 125 in the auto script |
+| Submodules not in sync | Wrong code being tested | Add `git submodule update --init --recursive` to the script |
+| Found a "bad commit" that's a merge | Probably a transient issue or skip-worthy | Inspect the merge: `git show --first-parent <merge>` |
+
+## Checklist
+
+```
+- [ ] Identified a clear known-good and known-bad commit
+- [ ] Have a deterministic, single-command reproduction
+- [ ] Repro is fast enough (<2 min ideally; bisect runs ~log₂(N) times)
+- [ ] Build can complete on every commit in the range (or skip script handles it)
+- [ ] Use `git bisect run <script>` for full automation
+- [ ] After hit: codragraph diff <bad>^ <bad> --semantic to understand WHY
+- [ ] git bisect reset before resuming work
+```
+
+## Example: "Tests started failing in the last 3 weeks"
+
+```bash
+# 1. Confirm endpoints
+git checkout main && npx vitest run path/to/regression.test.ts
+# → fails
+
+git checkout v1.5.3                        # known-good 3 weeks ago
+npx vitest run path/to/regression.test.ts
+# → passes
+
+# 2. Automate
+git bisect start main v1.5.3
+cat > /tmp/repro.sh <<'EOF'
+#!/usr/bin/env bash
+set -e
+npm install --silent || exit 125
+npx vitest run path/to/regression.test.ts --reporter=basic > /dev/null 2>&1
+EOF
+chmod +x /tmp/repro.sh
+git bisect run /tmp/repro.sh
+# → "abc1234 is the first bad commit"
+
+# 3. Understand the bad commit
+codragraph diff abc1234^ abc1234 --semantic
+# → modified validateUser (parameter count 3→4)
+
+codragraph_context({name: "validateUser"})
+# → caller `loginFlow` still passes 3 args — that's the regression
+
+# 4. Reset and fix
+git bisect reset
+# Patch the caller; tests pass; ship.
+```

package/skills/codragraph-git-force-push.md

@@ -0,0 +1,147 @@
+---
+name: codragraph-git-force-push
+description: "Use when the user is about to force-push, recovering after someone else force-pushed, or asking whether it's safe. Covers --force vs --force-with-lease, recovery from a bad force-push, and the rules for shared vs personal branches. Examples: \"force push\", \"is force push safe\", \"someone overwrote my work\", \"git push rejected\", \"--force-with-lease\""
+---
+
+# Force Push — When, How, and Recovery
+
+## When to Use
+
+- "Can I force push to this branch?"
+- "Git is rejecting my push, is force the answer?"
+- "Someone force-pushed and lost my commits — help."
+- "What's the difference between --force and --force-with-lease?"
+
+## The rules
+
+1. **Never `--force` on a shared branch** without coordinating. You will
+   silently overwrite collaborators' commits. Their reflogs save them; their
+   patience does not.
+2. **Always prefer `--force-with-lease`** over `--force`. It refuses the
+   push if the remote has commits you haven't seen — i.e. someone pushed
+   while you were rebasing.
+3. **Never force on `main` / `master` / `release/*`** unless you're recovering
+   from a documented incident with explicit sign-off. Branch protection
+   should make this impossible; if it's possible, fix the protection rule.
+4. **Force-pushing your OWN feature branch** after a rebase is normal and
+   expected. Just use `--force-with-lease`.
+
+## Decision tree
+
+```
+Is the branch protected on the remote?
+├─ yes → STOP. Don't force. Open a PR or get an admin to lift protection
+│        for a documented operation.
+└─ no → Is anyone else committing to this branch?
+        ├─ yes → STOP. Coordinate. They'll lose work if you force.
+        └─ no → Have you fetched the latest remote tip?
+                ├─ no  → git fetch first, then `git push --force-with-lease`
+                └─ yes → `git push --force-with-lease` is safe.
+```
+
+## --force vs --force-with-lease
+
+```bash
+# DANGEROUS: overwrites whatever is on the remote, no matter what.
+git push --force
+
+# SAFER: only succeeds if the remote tip matches what you last fetched.
+# If anyone pushed in the meantime, this aborts.
+git push --force-with-lease
+
+# EVEN SAFER: explicitly require the remote SHA to be what you expect.
+git push --force-with-lease=<branch>:<expected-sha>
+```
+
+> Make `--force-with-lease` your default by aliasing:
+> `git config --global alias.fwl 'push --force-with-lease'`
+
+## Recovery: someone force-pushed and lost your work
+
+Your local clone has the original commits in its reflog. You haven't lost
+anything as long as you haven't run `git gc --prune=now` AND your reflog
+is still intact (default 90-day expiry).
+
+```bash
+# 1. Find the lost commit on YOUR machine
+git reflog show <branch>
+# → look for "<branch>@{N}: ... before force push" or your last commit
+
+# 2. Inspect it
+git show <sha>
+git log <sha> --oneline -20
+
+# 3a. If they overwrote with rubbish: reset your branch to your old tip
+#     (this re-creates the divergence; coordinate before re-pushing)
+git checkout <branch>
+git reset --hard <sha-from-reflog>
+
+# 3b. If they had legitimate changes you also want to keep: cherry-pick
+#     YOUR lost commits onto their version
+git checkout <branch>
+git pull              # accept their version
+git cherry-pick <your-lost-sha-1> <your-lost-sha-2> ...
+
+# 4. Push back (with --force-with-lease to avoid the same problem)
+git push --force-with-lease
+```
+
+If the only copy of the lost commits was on the remote (no local clone),
+the recovery options are:
+
+- GitHub: contact GitHub Support — they retain dangling commits for ~30 days.
+- Self-hosted GitLab/Gitea: server-side reflog (if enabled) or a backup.
+
+## Recovery: I force-pushed something I shouldn't have
+
+If you JUST did it and have a terminal where the previous local state still
+exists:
+
+```bash
+git reflog                     # find the previous tip
+git reset --hard <previous-sha>
+git push --force-with-lease    # restore the remote
+```
+
+If you've already moved on locally:
+
+```bash
+git fetch origin
+git reflog show origin/<branch>
+# → look for the line BEFORE the force push you just did
+git reset --hard <recovered-sha>
+git push --force-with-lease
+```
+
+## Why CodraGraph helps here
+
+After a force-push (yours or theirs), `codragraph diff` against the
+recovered SHA tells you EXACTLY what structural changes were undone or
+reapplied — so you can verify nothing important got lost in the
+recovery:
+
+```bash
+codragraph diff <recovered-sha> HEAD --semantic
+# If addedAPIs / removedAPIs reveals work that should still be present,
+# the recovery is incomplete — go back to the reflog and pick more.
+```
+
+## Checklist (before any --force / --force-with-lease)
+
+```
+- [ ] Branch is NOT protected on the remote
+- [ ] Branch is NOT main / master / release/*
+- [ ] You're the only one committing to it (git log <branch> | grep -c Author)
+- [ ] You've git-fetched recently (so --force-with-lease has fresh info)
+- [ ] Using --force-with-lease, NEVER bare --force
+- [ ] If recovering: verified the recovered SHA via codragraph diff
+```
+
+## Pitfalls
+
+| Pitfall | What goes wrong | Avoidance |
+|---|---|---|
+| `git push -f` on shared branch | collaborators' commits silently gone | --force-with-lease + check `git log <branch>` for other authors first |
+| `--force-with-lease` after `git fetch` | lease check passes against the freshly-fetched tip — no protection | run lease BEFORE the fetch, or specify the expected SHA explicitly |
+| Force-push during CI run | CI race conditions, half-deployed states | wait for CI to finish, then force |
+| Forgetting reflog can save you | panic | reflogs default to 90 days; check `git reflog` before destroying anything |