Repository navigation
COOL IDEA™: advance producer pins by evidence-bearing PR, never by failing CI on staleness #31
Description
Activity
🔗 Related PRs
#17 - Prove durable Hello Echo execution [merged]
#20 - Record dependency-satisfied review outcomes [merged]
#21 - Prove typed Hello Echo result recovery [merged]
#22 - Prove bounded workspace observation [merged]
#24 - Prove basis-bound validated patch application [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.- Create Plan
🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:issue_enrichment: auto_enrich: enabled: false
💬 Have feedback or questions? Drop into our discord!
Current-head compatibility evidence, 2026-08-15:
- current Hello Echo
origin/main:1ad3f6de76344260c4488f08ed909172d96ae08e; - current Edict
origin/main:df80f92ad6242c6da31a64224666fd37aa43b0d0; - current Echo
origin/main:490134c0753a3df6a74da366cc71c1248764dc5a.
A disposable probe changed only the Echo coordinate in the current-main producer lock and passed
tests/runtime.sh,tests/effect-runtime.sh, andtests/patch-runtime.sh. This proves the current heads are locally compatible across the pure runtime, bounded observation, and basis-bound patch witnesses; it does not alter the canonical pin or replace reviewed CI.The concrete manual pin advancement is now tracked by #33. This issue remains the durable scheduled-advisory mechanism and should not turn pin staleness into required red CI.
- current Hello Echo
The concrete papercut, already loaded
flyingrobots/edictbranchdocs/action-rename-upkeeprenames Intent → Action workspace-wide. It is unmerged. The pinned Edict (df80f92a) still parsesintent, and all three.edictsources here still sayintent:src/hello_echo.edicteffect/src/observe-workspace.edictpatch/src/apply-validated-patch.edictWhen that branch lands, advancing
producers.lock.jsonand renaming those sources must happen in one commit, or the build fails closed. That is the pin working correctly. It is also a manual step nobody is currently scheduled to notice.The wrong fix
Failing CI when a pinned producer trails its
main. That makes reproducibility subordinate to novelty. An exact lock exists to preserve a known basis; the producer advancing does not invalidate that basis. A stale pin is maintenance information, not a broken proof.The right shape
Two mechanisms, deliberately separated:
Required CI — unchanged:
Scheduled advisory — new, never blocking:
producers.lock.jsonon a branchintent→actionis the live example)Freshness becomes a proposed event with evidence attached, rather than either ambient drift or a red build.
Why now
The rename is the first migration that will actually require step 3. Building the mechanism after it bites is strictly worse than building it while there is exactly one known migration to encode.
Acceptance
intent→actionmigration is encoded as its first case.Provenance
Surfaced by an external review; the failing-CI-on-staleness version was my own suggestion and was wrong for the reason above.