# Capture changes into my fork

You're integrating one or more commits from a sibling GitHub fork into
the CURRENT WORKING DIRECTORY. The CWD should already be a clean git
working tree on a branch you're willing to commit to.

## Source commit: Centralize shared project lookup encoding

| # | SHA | Subject | Fork | Authored |
|---|-----|---------|------|----------|
| 1 | [`bbd8de44`](https://github.com/CaliLuke/mike/commit/bbd8de44d6bdf346768d1dcd9da3398684449143) | Centralize shared project lookup encoding | `CaliLuke/mike` | 2026-05-05 |

### Commit URLs (for your tooling)

1. https://github.com/CaliLuke/mike/commit/bbd8de44d6bdf346768d1dcd9da3398684449143

## What I want you to do

1.  **Sanity check first.**

    - Run `git status`. If the working tree is dirty (uncommitted
      changes you don't recognise, untracked stuff you don't expect),
      STOP and tell me — don't try to be helpful by stashing. I'll
      resolve it.
    - Run `git branch --show-current`. If the branch is `main` or
      `master`, confirm with me before proceeding.

2.  **For each commit URL above, in the order listed:**

    a.  Fetch the diff. Pick whichever works:
        - `gh api repos/<owner>/<repo>/commits/<sha>` returns the full
          patch in JSON.
        - WebFetch the URL with `.patch` appended, e.g.
          `https://github.com/<owner>/<repo>/commit/<sha>.patch`.

    b.  Read the original commit message. That's the AUTHOR's intent —
        respect it.

    c.  Read the diff and understand the change. **Don't blindly
        cherry-pick.** This is a sibling fork — paths, naming, and
        structure can differ. You're porting, not pasting.

    d.  Compare against THIS repo's layout:
        - File at the same path → apply the change.
        - File exists under a different name (renamed / restructured) →
          apply the equivalent change at the right location.
        - File doesn't exist here at all → decide: new file we want, or
          is the source adding something this repo already has by
          another name? Use judgement. Lean towards creating the file
          when in doubt — easier for me to delete than to recreate.

    e.  Apply the change. Run `git diff` after, eyeball it, fix
        obvious issues (lint errors, broken imports, typos in the diff
        itself).

    f.  Commit with a message that:
        - Preserves the source commit's subject line.
        - Adds a short body explaining what you adapted, if anything.
        - Includes trailers:

              Source: <commit-url>
              Source-author: <original author name>

        so the attribution stays clear.

3.  **After all commits are applied:**

    - Run `git log --oneline -<count>` showing what you produced.
    - Show `git status` final state.
    - List any files you skipped, conflicts you resolved, and any
      assumptions you made.

## Rules

- **Do not push.** Local commits only. I'll review and push.
- **Do not rebase or force.** Only fresh commits. If you'd otherwise
  need a force push, stop and explain why.
- **Don't touch `.git/config` or run `git remote add`.** Leave my
  repo's remote setup alone.
- **No package installs, build steps, or migrations** unless the
  change manifestly requires it AND you explicitly tell me what
  you're about to run first.
- **One commit per source commit.** Don't squash. Don't split. If
  porting genuinely requires either, explain.
- **Read existing code before changing it.** This isn't the source
  fork. Match the local style.

## If you get stuck

Stop and tell me. Show what you've already done (commits made, files
changed), what blocked you (conflict, missing file, ambiguous intent),
and your recommended next move. I'd rather ship 3 of 5 commits cleanly
than have you guess on the 4th and break things.