examples: add lift-upstream and block-escalate proof bundles#95
Conversation
Add the remaining two routed-outcome proof bundles for the springboot-platform-app example: - lift-upstream: read-only Redis caching request bundle with render-diff, explain, and verify scripts - block-escalate: read-only datasource override boundary bundle with render-attempt, explain, and verify scripts Both bundles are deterministic and read-only. They prove the three-outcome mutation model without requiring a live cluster or real GitHub PR automation. Replaces PRs #87 and #89 which were stacked on intermediate branches that no longer exist after squash merges. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5a1f6fc189
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "durable_upstream_changes": [ | ||
| "Add spring-boot-starter-data-redis dependency", | ||
| "Set spring.cache.type=redis in the upstream app config" |
There was a problem hiding this comment.
Include actual cache behavior in the lift-upstream bundle
When someone applies the advertised ./lift-upstream.sh --render-diff patch, the upstream side only adds the Redis starter and spring.cache.type=redis. None of the Java sources change, and the app still has no caching behavior wired in, so this bundle does not actually implement the request in show_explain_json (“Add Redis-backed caching to the service.”) — it only changes dependencies/config. The proof bundle should include the code changes that make requests hit Redis-backed caches, otherwise the “GitHub-ready” diff is materially incomplete.
Useful? React with 👍 / 👎.
| for pair in "${PAIRS[@]}"; do | ||
| IFS='|' read -r target current lifted <<<"${pair}" | ||
| set +e | ||
| diff -u --label "a/${target}" --label "b/${target}" "${current}" "${lifted}" |
There was a problem hiding this comment.
Compare the rendered Redis patch against a frozen baseline
render_diff() is diffing each bundle snapshot against whatever currently exists in upstream/app/... and confighub/.... If any unrelated edit lands in those files later, ./lift-upstream.sh --render-diff will start emitting that drift too, even though the docs call this a deterministic Redis bundle. Without a frozen baseline (or at least a guard that the source files still match the expected starting point), reviewers can get a noisy patch that is no longer the Redis-only change this script is supposed to prove.
Useful? React with 👍 / 👎.
Summary
./lift-upstream.sh,--explain,--render-diff, and./lift-upstream-verify.sh./block-escalate.sh,--explain,--render-attempt, and./block-escalate-verify.shThis completes the three-outcome mutation model for
springboot-platform-app:Replaces #87 and #89 which had stacking issues after squash merges.
Verification
All pass:
./scripts/verify.sh./verify.sh./lift-upstream-verify.sh./block-escalate-verify.shmvn test(3 tests, 0 failures)Test plan
🤖 Generated with Claude Code