# 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 thread: Allow personal Case.dev keys in demo mode

## Summary\n- Make hosted Demo Mode use the shared Case.dev key only when a user has not saved a personal Case.dev key.\n- Allow users to save or clear their own Case.dev key in Demo Mode; clearing falls back to the shared demo key.\n- Update Account > Models copy and controls so the demo key is the default, while personal Case.dev keys can override it.\n- Keep Anthropic/Gemini direct-provider keys disabled in the hosted demo UI for now.\n- Removed the production MIKE_DEMO_GLOBAL_BUDGET_USD env var so the hosted demo uses the per-user budget without an accidental shared global  cap.\n\n## Verification\n- Prod API currently returns demo source and live Case model catalog for scott@kveton.com.\n- npm run build --prefix backend\n- cd frontend && npx tsc --noEmit\n- git diff --check PR CaseMark/mikeoss-casedotdev ← CaseMark/mikeoss-casedotdev #4, by kveton.

| # | SHA | Subject | Fork | Authored |
|---|-----|---------|------|----------|
| 1 | [`4a979679`](https://github.com/CaseMark/mikeoss-casedotdev/commit/4a9796798a49f1c2d0edd15e15c7eb54650524f7) | Allow Case key override in demo mode | `CaseMark/mikeoss-casedotdev` | 2026-05-04 |

### Commit URLs (for your tooling)

1. https://github.com/CaseMark/mikeoss-casedotdev/commit/4a9796798a49f1c2d0edd15e15c7eb54650524f7

## 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.