Repository navigation
Adopt released Core v0.19.8: authenticated-v2 process groups, verified release publication, stamped generated clients, and runnable-bindings --check on a fresh checkout - #1209
Merged
antoinetoussaint-byte merged 10 commits intoOct 28, 2026
Conversation
…eck can run on a fresh checkout `codefly generate runnable-bindings` walks every composed module for its derived operations, but loaded the workspace with the plain loader. On a composition of pinned modules with no codefly.local.yaml — a CI job, or any fresh checkout — it refused before reading anything: module <wiki> resolves to a pinned artifact (source "obin-ai/core-solutions", version "0a18964f…"); pinned modules are pulled by the CLI, not loadable as a local checkout so `--check`, the one drift check this generated group has, could not be run where drift is caught. The command now materializes pinned modules first, exactly as `codefly run`, `deploy gitops render` and `generate fixture-composition` do (common.LoadWorkspaceWithPinnedModules), and is free once the workspace is materialized. Verified on obin-ai/platform-obin main (694ac3f4), environment blue: before, the refusal above; after, the check reaches the regeneration and refuses with the composition's real contradiction — `--call-endpoint "saas/auth-gateway/hop": service saas/auth-gateway declares no endpoint hop (it declares [grpc rest workload])` — while the committed configurations/blue/runnable-bindings.env binds 17 operations to their owners' direct in-cluster addresses, two of them on module compute, which the composition does not compose. First slice of making render and deploy refuse committed generated output that no longer matches what the generator would produce; the generic check on the readiness gate follows (see the handoff). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…t/runnable-bindings-check-materializes
…runnable-bindings materializes pinned modules The two narrative edits the #1208 docs closure left (codex-cli1208-e9-docs-closure): docs/runnable.md says a failed preparation writes no binding output and preserves the existing binding, rather than "writes nothing", since the loader now materializes a pinned module first; docs/commands.md lists `generate runnable-bindings` (its `--check` included) among the commands that materialize, distinguishing cache/overlay/receipt/.gitignore writes from binding output. No code; the --check row, flag help and docs/cli-reference.md were already corrected in this stack. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This was referenced Oct 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why this lands as one PR, and before v0.1.220
Core v0.19.8 writes process-group records to the
authenticated-v2namespace (withlaunch_workspace). cli main's reader (pkg/processgroup/reaper.go) scans onlyauthenticated-v1plus the loose legacy root, so a CLI pinned to the released core strands every process group Core creates:TestWorkspaceHostReapsProcessGroupsLeftByDeadInProcessOwnersfails on main + core v0.19.8 (5.14s, exit 1) and passes on this head + the same core (0.19s, exit 0) — proof at/tmp/codex-cli1205-core198-reader-proof.md. That test is right and is not moved; birth checks are not weakened; v2 is not dropped. The orphaned-branch pseudo-version6eadd92dthat main pins today predates the squash by 80 minutes and still wrote v1, which is why main looked green.So the core re-pin (#1205) cannot land without this reader rework, and the reader rework is the stop/processgroup half of this stack. The stack is opened at exactly
e9cf1cf867f53b3cfb475047e82736544a8ded24, 9 ahead of main, nothing re-implemented or edited; it is the head whose all-required CI was green (19 success, 1 cancelled, 1 skipped).What is in it
1fac1a7c—generate runnable-bindingsmaterializes pinned modules so--checkruns on a fresh checkout (the slice also open as generate: runnable-bindings materializes pinned modules, so --check can run on a fresh checkout #1208; generate: runnable-bindings materializes pinned modules, so --check can run on a fresh checkout #1208 is superseded by this PR once it merges).91ff4342,ddd27e67— release publication verifies downloaded archives against producer checksums and GitHub digests, checks installer credentials through Core, stamps tracked generated client libraries through the existing release transaction; Python stamps the TOMLproject.versionby ownership.cefe5375,293c2919,97966193,8add9461—codefly stop/ processgroup consume Core's authenticated registry APIs (ListProcessGroups, owner provenance, persisted launch workspace), preserve incompatible birth evidence, refuse marker-only signalling, cannot bypass a registry refusal through agent-name or orphan fallback kills, bounded reconciliation across mixed producer generations; each preserved group reported once.e9cf1cf8— merges the container-attribution fix and adopts released Core v0.19.8.Independent reviews on file (by path)
/tmp/codex-cli-stop-final-closure.md/tmp/codex-cli-python-stamp-rereview.md/tmp/codex-cli-publication-review.md/tmp/codex-cli1205-core198-reader-proof.mdOrder after this merges
#1205 (core → tag
v0.19.8, tidy) rebased onto it; then #1204 (queued), #1206, #1208 closed as superseded. v0.1.220 = main + this + #1204 + #1205 + #1206.🤖 Generated with Claude Code
Docs follow-up on this PR (head
31387a56)One docs-only commit on top of the reviewed
e9cf1cf8— the stack itself is unedited. It carries the two narrative corrections #1208 owed (that PR is closed, superseded by this one):docs/runnable.md— a failed preparation preserves the existing binding; it does not "write nothing".docs/commands.md— the "Which commands materialize" list now includesrunnable-bindings(including--check), distinguishing dependency cache / overlay / receipt /.gitignorewrites from binding output, which--checkstill never writes.Documents updated by this PR:
docs/commands.md,docs/runnable.md.