Keep the upstream. Add your own.

Open a terminal in that folder. The second line stops if the patch does not apply.

node app.mjs
git apply --check feature.patch && git apply feature.patch && node app.mjs

Open PowerShell in the folder. This works with Windows PowerShell 5 and newer PowerShell versions.

node app.mjs
git apply --check feature.patch
if ($LASTEXITCODE -eq 0) {
  git apply feature.patch
  if ($LASTEXITCODE -eq 0) { node app.mjs }
}

Open both practice files and paste their contents, along with the prompt below, into an assistant you trust. Ask it to predict the before and after output and identify the changed line. Compare its answer to the result shown above. This is a reading exercise: the phone app does not apply the patch unless you separately provide a compatible environment and authorized tools. No plugin, MCP server or paid service is required.

In the same folder, also download two-repo-lab.sh. Read it before running it. In a Linux or macOS terminal, or Git Bash on Windows, run sh two-repo-lab.sh. It creates a temporary upstream repository and a separate patch repository, commits their submodule pins in a third repository, checks and applies the patch, and prints the before and after output. It removes the temporary repositories when it exits. Local file transport is enabled for those two practice commands only; global Git settings are not changed. No network access or Renovate installation is involved.

Outcome: a verifiable changed message. Harness and model: any assistant and model you can access, optional for the command-line exercise. Instructions and context: the prompt, original file, patch and your intended use. Roles: an inventory agent, implementation agent and independent reviewer can be separate people or agent sessions; you decide and verify. Tools: Git and Node.js for the computer exercise; a browser and assistant suffice to inspect it on a phone. No skill, MCP server, plugin or external API is required. Verification: run the original, check and apply the patch, run again, then deliberately test an incompatible change.

With app.mjs and feature.patch from Module 1 in a disposable folder, download upgrade-loop.sh into the same folder. Read it first, then run sh upgrade-loop.sh in a Linux or macOS terminal or Windows Git Bash. It needs Git, Node.js, tar and mktemp.

The script creates two local repositories and commits their pins. It builds an initial artifact, simulates a compatible upstream update and builds again, then simulates a conflicting update. The conflict stops the third build, and the script runs the previous good practice artifact. It removes its temporary repositories and files on exit. The pin updates are simulated with Git: this exercise does not install or run Renovate, contact a server or deploy a release. In a real pipeline, retain your complete release artifact and follow your own review and rollback process.

In a Linux or macOS terminal or Windows Git Bash, start from a clean composition repository and replace the placeholders with your own approved Git URLs and reviewed full commit IDs. The custom repository must contain your independently authored feature.patch at its root for the example below. Configure Git identity and any required repository access through your organization's approved method; do not put credentials in URLs. Commit the submodule pointers, then let Renovate propose changes for review.

# In your own clean composition repository, replace each placeholder.
git submodule add 'YOUR_REVIEWED_UPSTREAM_URL' vendor/upstream && \
git submodule add 'YOUR_REVIEWED_CUSTOM_REPO_URL' vendor/custom && \
git -C vendor/upstream checkout --detach 'YOUR_REVIEWED_UPSTREAM_COMMIT' && \
git -C vendor/custom checkout --detach 'YOUR_REVIEWED_CUSTOM_COMMIT' && \
git add .gitmodules vendor/upstream vendor/custom && \
git commit -m 'Pin upstream and customization'