Repository navigation
The host-boundary paragraph named a mechanism #11528 deleted - #11561
Merged
Merged
Conversation
gunbc#11528 deleted the workflow-function concept at 00:43Z. This paragraph, landed in #11518 a few hours earlier, still explained the `Filesystem.Read` refusal with "resource operations resolve only inside a workflow function". That sentence is now wrong twice over, and the second way was wrong before the deletion. `workflow` was never a semantic kind -- it was one emitter predicate, `v1.compiler.emit_rust` `is_workflow_item`, true when a function carried `uses`, when the registry held a service or resource name, or when the registry held nothing at all. #11528's census states the consequence directly: `v1.compiler.infer` gates no resource operation on workflow, because admissibility is the `uses` clause binding the resource into body scope. So the paragraph attributed a real refusal to a function KIND when the gate is a declared EFFECT REQUIREMENT, and then the kind was deleted. What is unchanged is the measurement: `Filesystem.Read` off a plain `fn` is still a located refusal, "receiver type 'Primitive(Filesystem)' establishes no method surface". Only the explanation moves. RECORDED RATHER THAN QUIETLY REWRITTEN, because this is the second correction to the same paragraph in one night and the first one preserved the clause that was wrong. #11526 corrected its CONCLUSION (a fold cannot read a file -- false; `filesystem_read` is a bridged free primitive), and I kept "because resource operations resolve only inside a workflow function" as the surviving measured half. It was the half to cut. A paragraph can be corrected and still carry its original defect if the correction only touches the sentence that was challenged. TWO SIBLINGS LEFT ALONE AND NAMED SO THEY ARE NOT LOST. `gunbc.design_document` carries the same clause in the Two CLIs rule -- that paragraph is #11526's open subject, so it belongs to that PR rather than this one. `v1.compiler.compiler_tests_rust` carries the phrase inside an assertion MESSAGE whose subject (an entry-absent main must refuse) remains valid; that is stale phrasing, not a false claim, and editing it costs a seed regen for no correctness gain. Annotation only (DESIGN section 4c): no semantic graph, hash or emitted-byte change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
briansrls
added this pull request to the merge queue
Sep 18, 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.
src/v2/cli/compile_cli.dagexplained theFilesystem.Readrefusal with "resource operations resolve only inside a workflow function". #11528 deleted the workflow-function concept at 00:43Z, a few hours after that paragraph landed in #11518.The clause was wrong before it was stale
workflowwas never a semantic kind. It was one emitter predicate —v1.compiler.emit_rustis_workflow_item, true when a function carrieduses, when the registry held a service or resource name for it, or when the registry held nothing at all. #11528's own census states the consequence:v1.compiler.infergates no resource operation on workflow, because admissibility is theusesclause binding the resource into body scope.So the paragraph attributed a real refusal to a function kind when the gate is a declared effect requirement — and then the kind was deleted out from under it. The ruling is D12 in
gunbc.plans.demand_engine_program, which also keepsusesat its one meaning.The measurement is untouched.
Filesystem.Readoff a plainfnis still a located refusal: receiver type 'Primitive(Filesystem)' establishes no method surface. Only the explanation moves.Why this is the paragraph's second correction in one night
#11526 challenged its conclusion — "a
.dagfold cannot read a file", false, sincefilesystem_readis typed byv1.compiler.infer_methodbuiltin_function_registry, bridged byextdeps.languages.rust.emitrt_function_registry, and realized byv1.compiler.runtime_rustrt_filesystem. I rewrote around that and kept the "workflow function" clause as the surviving measured half. It was the half to cut.Recorded in the commit rather than quietly rewritten, because the pattern generalises: a review finding scopes your attention, and that scope is not a guarantee about the rest of the paragraph. A paragraph can be corrected and still carry its original defect.
Two siblings deliberately left alone
gunbc.design_documentcarries the identical clause in the Two CLIs rule. That paragraph is DESIGN: an emitted binary can read files; the CLI's walk stays in main for two narrower gaps #11526's open subject — it belongs to that PR, and it needs this second correction on top of the one it was opened for, or DESIGN lands a retraction that itself carries a retracted mechanism.v1.compiler.compiler_tests_rusthas the phrase inside an assertion message whose subject (an entry-absent main must refuse) remains valid. Stale phrasing, not a false claim; editing it costs a seed regen for no correctness gain.Scope
Annotation only. DESIGN §4c: annotation capture is disjoint from semantic occurrence allocation, so this cannot alter the semantic graph, any hash, or the emitted bytes.
🤖 Generated with Claude Code