AI overwrites my fixes · ConfigHub Workshop

Run it yourself

The journey is a folder in the public workshop-demo repository. Its script pauses before each command, and Enter runs it. Read each command before continuing; stop with Ctrl+C whenever you have the result you need. ConfigHub sign-in, upload and protected-update steps are optional later work, not prerequisites for the local check.

# get the journeys
$ git clone https://github.com/monadic/workshop-demo

# use the version this page describes
$ git -C workshop-demo checkout --quiet 0e91722fb417

# open this journey
$ cd workshop-demo/2-my-fixes-survive

# walk the steps, one command at a time
$ ./run.sh

Or let your agent run it

Give your agent the journey's PROMPT.md and nothing else. It follows the same steps, with the same numbers, and shows you the command after each one. You decide at each step whether to go on.

Keep this page and the README from your agent. They say what each step finds, so an agent that reads them knows the answers before it starts.

The steps

These are the steps in the journey's README. Run them from the journey's folder. The output of a real run is in expected/.

# the steps write their output here
$ mkdir -p work

1. Look at the three fixes you made by hand

grep shows the three lines in app-committed.yaml.

$ grep -n -e "replicas:" -e "db.shop.internal" -e "memory: 512Mi" app-committed.yaml

Look for three replicas, the real database host, and a 512Mi memory limit.

2. Look at the file the assistant wrote today

New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.

$ cub config check app-regenerated.yaml

Two objects, nothing to worry about. It would deploy.

3. Compare it with what you are running

$ cub config diff app-committed.yaml app-regenerated.yaml

Look for four changed fields in the Deployment. One is the readiness probe you asked for. The other three are your fixes undone: replicas 3 to 1, the database host back to localhost, the memory limit from 512Mi to 128Mi. Each is named by its exact path inside the container.

4. Put your fixes back, and compare again

$ cub config diff app-committed.yaml app-restored.yaml

Look for one changed field, the probe. That is the change you asked for, and nothing else.

5. Keep a record of the review, and make it a gate

With --exit-code any change stops for a review, and --out writes both file hashes and every changed field to work/review.json.

$ mkdir -p work

$ cub config diff app-committed.yaml app-regenerated.yaml --exit-code --out work/review.json

$ grep -e '"sha256"' -e '"changed"' -e '"path"' work/review.json

The diff exits 1 because fields changed, which is what stops a build. Look for two sha256 lines, which pin the record to these exact files, and one path line for each field that changed.

6. With ConfigHub, let it remember your fixes

Step 4 was you, putting your fixes back by hand, and it will happen again next week. Log in with cub auth login first.

Use these commands as the manual route, or use DEMO_SPACE=my-workshop-space ./run.sh 6 and the same value with ./run.sh 7 as the script route. Do not mix them: the manual route does not write the local record that lets script step 7 continue, and script step 6 refuses a Space the manual route already created.

$ export DEMO_SPACE=my-workshop-space

$ cub space create "$DEMO_SPACE"

$ cub unit create --space "$DEMO_SPACE" shop-web-generated app-generated.yaml

$ cub unit create --space "$DEMO_SPACE" shop-web --upstream-unit shop-web-generated --upstream-space "$DEMO_SPACE"

$ cub unit update --space "$DEMO_SPACE" shop-web app-committed.yaml --protect --change-desc "my three hand fixes"

$ cub revision list --space "$DEMO_SPACE" shop-web

The assistant's output lives in one Unit and your copy is cloned from it. --protect records the paths changed by your three fixes as local overrides. A plain update records a revision but does not newly protect those paths from a competing upstream edit.

7. Let the assistant rewrite it again

Today's rewrite lands in the assistant's Unit, and one command brings it into yours.

$ export DEMO_SPACE=my-workshop-space

$ mkdir -p work

$ cub unit update --space "$DEMO_SPACE" shop-web-generated app-regenerated.yaml --change-desc "add a readiness probe"

$ cub unit update --space "$DEMO_SPACE" shop-web --upgrade

$ cub unit data --space "$DEMO_SPACE" shop-web > work/from-confighub.yaml

$ cub config diff app-committed.yaml work/from-confighub.yaml

Look for one changed field, the probe. Your three fixes are still there, and nobody put them back by hand. ConfigHub did step 4 for you. This step 7 comparison proves that it retained your configuration and added only the probe.

These two steps write to a new Space you choose in the organization your current cub context points at. Set a name you own with DEMO_SPACE=my-workshop-space ./run.sh 6, then use the same value for step 7. The script creates the Space once and stops if that name already exists; it never deletes or reuses an existing Space. It records the Space ID and server identity locally, and step 7 checks both before changing anything. DEMO_CONTEXT=name picks another context. ./run.sh --reset removes local work/ only and leaves the Space unchanged.

Use it on your own configuration

Compare the file you run with the one your assistant wrote. Put the file you run first, so that each change reads from yours to the rewrite. The diff names every field that moved, and with the exit code set a change fails the build until someone reviews it.

# name every field the rewrite changed
$ cub config diff <the-file-you-run>.yaml <the-file-it-wrote>.yaml --exit-code

These Guides go further: Add one field and keep the original configuration · Variants.

Why it happens

Variants explains it.

Where it continues

ConfigHub Server, which carries your fixes through the next rewrite. The next journey is My app does not fit my platform.