Skip to content

The host-boundary paragraph named a mechanism #11528 deleted - #11561

Merged
briansrls merged 1 commit into
mainfrom
workflow-clause-correction
Sep 18, 2026
Merged

briansrls merged 1 commit into
mainfrom
workflow-clause-correction

Conversation

@briansrls

@briansrls briansrls commented Sep 18, 2026 •

Copy link
Copy Markdown
Contributor

src/v2/cli/compile_cli.dag explained the Filesystem.Read refusal 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

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 for it, or when the registry held nothing at all. #11528's own census states the consequence: 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 out from under it. The ruling is D12 in gunbc.plans.demand_engine_program, which also keeps uses at its one meaning.

The measurement is untouched. Filesystem.Read off a plain fn is 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 .dag fold cannot read a file", false, since filesystem_read is typed by v1.compiler.infer_method builtin_function_registry, bridged by extdeps.languages.rust.emit rt_function_registry, and realized by v1.compiler.runtime_rust rt_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_document carries 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_rust has 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

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>
@gunbai-bot gunbai-bot Bot changed the title v2 self host frontier The host-boundary paragraph named a mechanism #11528 deleted Sep 18, 2026
@gunbai-bot
gunbai-bot Bot marked this pull request as ready for review September 18, 2026 02:18
@briansrls
briansrls added this pull request to the merge queue Sep 18, 2026
Merged via the queue into main with commit 4cdbd79 Sep 18, 2026
4 checks passed
@briansrls
briansrls deleted the workflow-clause-correction branch September 18, 2026 05:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant