CG: unify TLC-2 dual authority, mark transport/config complete

[briansrls]

Summary

• SimpleMethodSpec type co-locates template + wraps_result flag for simple method templates (same pattern as HigherOrderMethodSpec). Both rust_method_templates() and rust_method_wraps_result() now derive from rust_simple_method_specs — eliminates parallel data maps as dual authority.
• Transport/config centralization marked [x] — remaining per-backend rendering is inherent language differences addressed by the 3→1 homomorphism.
• Flagged Go op_children filter inconsistency in emit_go_service_def (Rust/Python don't filter by params).
• Two new parity tests: method_wraps_result_derived_from_specs, method_templates_derived_from_specs.

Test plan

• cargo test -p v2-compiler-tests — 316 pass, 0 fail
• cargo clippy --all-targets -- -D warnings — clean
• ./scripts/check-stage0-freshness.sh — fresh
• New parity tests validate derived maps match spec list

🤖 Generated with Claude Code

[briansrls]

ChatGPT Review

Based on the uploaded diff, this is a good refactor in principle, but I would not rubber-stamp it as-is.

The core refactor is directionally right. Moving from two parallel Rust method tables to one SimpleMethodSpec authority in dsl/extdeps/languages/rust/emit.dag, then deriving rust_method_templates() and rust_method_wraps_result() from that single source, is exactly the kind of “delete the duplicate representation and compute the consumer view from the authority” change the invariants want. The .dag side is cleaner after this change, and the new source-audit tests are good guardrails against drift. INVARIANTS

My main concern is the stage0 implementation of that refactor. In the generated Rust, the old cached rust_method_templates / rust_method_wraps_result maps are gone, but the replacements are not cached as maps anymore. rust_simple_method_specs() is cached, but rust_method_templates() now folds a new HashMap on every call, and rust_method_wraps_result() now allocates a filtered vector and folds a new map on every call. Then rust_runtime_bridge_wraps_collection_result_in_rc() calls rust_method_wraps_result() for lookups. That turns a one-time index into repeated allocation and rescanning in an emitter decision path. Given how strongly INVARIANTS.md treats repeated rescans / allocation churn / “one scan turns into N scans” as correctness bugs, I think this is a real issue, not just a micro-optimization nit. I would keep rust_simple_method_specs() as the single authority, but restore cached derived maps in stage0. INVARIANTS

So my review summary would be: request changes for the caching regression, even though the authority unification itself is good.

On roadmap alignment, I’d split the claims:

TLC-2 is plausibly complete in the narrow sense used by this PR. If the claim is “the last local parallel authority for simple Rust method template wrapping is gone,” then yes, the diff does that. SimpleMethodSpec now co-locates template and wraps_result, and both consumer maps derive from it.

But TLC-2 is not obviously complete in the broad architectural sense implied by the label “runtime bridge signature derivation.” This PR unifies one Rust extdep sub-authority; it does not fully solve the broader “same type/coercion authority as emission” problem across the lane. I would not object to the checkbox if you intend the narrow reading, but I would avoid overselling it in prose. Related method/coercion modeling work is still explicitly open in the roadmap (partial_function_templates, CallableOf). ROADMAP

I do not think “Transport/config complete” is justified by this diff. The only transport/config code change here is a new comment in 05_emit_go.dag that explicitly calls out a live backend inconsistency: Go filters op_children by params, while Rust/Python use item.children unfiltered. The code remains inconsistent. Marking the lane complete in ROADMAP.md while adding a BUG: comment about an unresolved backend divergence sends the opposite signal from “complete.” I’d leave that roadmap item partial unless there is supporting code elsewhere in the branch that is not in this diff.

On compositional modeling quality, the .dag change is solid. SimpleMethodSpec is a reasonable product type, and it matches the existing HigherOrderMethodSpec style rather than adding another ad hoc table. That is good modeling. My only modeling nit is operational: if direct lookup is the dominant use, the authoritative runtime shape may want to be a keyed map of specs or a cached derived index, not a list that gets re-folded into maps repeatedly. That is more of a performance/composition concern than a faithfulness concern.

A couple smaller code-review notes:

The new tests are useful, but they only prove parity between the list and the derived maps. They do not prove that the actual consumer behavior stayed correct. I’d add one direct consumer-level test around rust_runtime_bridge_wraps_collection_result_in_rc() or a tiny emit fixture that exercises both paths (join false, split true, etc.).

The Go BUG: comment should ideally either become a fix in the same PR or be tied to a tracked issue. As written, it documents a real cross-backend divergence without changing behavior, which makes the new roadmap checkbox harder to defend.

I don’t see a new invariant violation in the authority refactor itself. The invariant problem I do see is the likely stage0 performance regression from uncached repeated derivation. And I’d push back on the transport/config completion claim. Everything else looks reasonable.

---

View conversation

[briansrls]

Review (INVARIANTS: 1, MODELING: 2+/2-, ROADMAP: 1✓/1!)

INVARIANTS — Violations (1)

ROOT CAUSE ANALYSIS

• src/v2/05_emit_go.dag Upstream, there is no shared structural authority defining which service children are emitted as operations (gap in shared emit traversal modeling), so Go applies an ad-hoc backend filter while other emitters use full item.children; this drops zero-arg ops in Go and creates backend-inconsistent emitted APIs; fix it by defining one shared predicate/list in a common emitter authority (e.g., via shared service-shape dispatch in 05_emit or 04_resolve) and remove backend-local filtering (MODELING M8/M3).

MODELING — Strengths

• dsl/extdeps/languages/rust/emit.dag SimpleMethodSpec centralizes template + wrapping intent in one record and derives both maps from that single authority, which is a clean compositional correction of the prior parallel-map duplication.
• src/v2/languages.dag Switching method_templates to rust_method_templates() correctly treats LanguageSpec as a consumer of derived extdep facts.

MODELING — Improvements

• dsl/extdeps/languages/rust/emit.dag method_name remains string-keyed; if method names are constrained, model them as a structural enum/coproduct rather than strings and keep this authority reused across language extdeps for clearer algebraic dispatch (MODELING M4).
• src/v2/languages.dag Mirror this constructor-style import pattern across all backends so adding languages cannot accidentally pass data constants instead of canonical derived accessors.

ROADMAP — Verified

• TLC-2: Runtime bridge signature derivation: The PR’s code changes add and consume SimpleMethodSpec/derived maps plus tests, directly matching the claimed single-authority consolidation.

ROADMAP — Incomplete

• Transport/config: The roadmap marks this lane complete, but this diff still leaves backend divergence in operation-set traversal and no emitted proof that the 3→1 service emission model is fully enforced.

The PR mostly aligns with the single-authority direction and closes the runtime wrap-result duplication, but it still leaves a backend-service traversal inconsistency unresolved.

[briansrls]

Review (INVARIANTS: 0, MODELING: 3+/2-, ROADMAP: 0✓/0!)

MODELING — Strengths

• src/v2/05_emit.dag Promotes compositional homomorphism by centralizing repeated ExprVar/FieldAccess/Call/Index/Slice/Cast lowering into shared helpers, matching the emit_shared_expr authority-driven pattern from the shared expression contract.
• dsl/extdeps/languages/rust/emit.dag SimpleMethodSpec lifts method render/wraps_result metadata into one layer-2 authority, and folds this once into rust_method_templates() and rust_method_wraps_result(), which is strong M7 single-authority modeling.
• src/v2/languages.dag Binding method_templates to rust_method_templates() keeps LanguageSpec as a consumer of extdep facts instead of owning backend method templates, preserving layer separation.

MODELING — Improvements

• src/v2/05_emit.dag Could further improve structural safety by moving the remaining variant-specific mismatch behavior into a single shared dispatch guard so all backends fail uniformly instead of relying on call-site correctness.
• dsl/extdeps/languages/rust/emit.dag A shared MethodTemplateSpec pattern between SimpleMethodSpec and existing HigherOrderMethodSpec would reduce schema drift and make future method-family extensions more regular at L2.

This PR materially improves single-authority modeling and removes a prior Go service-traversal bug, with no new invariant violations introduced.

[briansrls]

ChatGPT Review

Verdict: good direction, but I’d request changes before merge.

The core TLC-2 refactor is real. Replacing the parallel Rust simple-method tables with one SimpleMethodSpec authority in dsl/extdeps/languages/rust/emit.dag, then deriving both rust_method_templates() and rust_method_wraps_result() from it, is exactly the right shape. The shared emit extraction in 05_emit.dag is also solid compositional cleanup: it removes repeated backend-local ExprData matching and pushes more logic into shared helpers/accessors.

The main thing I would block on is a stage0 performance/cost-model regression. In src/v2/stage0/src/extdeps_languages_rust_emit.rs, rust_simple_method_specs() is cached, but rust_method_templates() and rust_method_wraps_result() now rebuild fresh HashMaps every call by folding over that list. Then rust_runtime_bridge_wraps_collection_result_in_rc() consults rust_method_wraps_result() for membership, so a lookup path that used to read a cached map now rescans and reallocates first. Under the repo’s Performance Invariant, that is the wrong direction: it explicitly calls out “one scan turns into N scans” and prefers one-time indexing/O(1) lookup over repeated rescans. INVARIANTS

INVARIANTS

So my main requested change is: keep SimpleMethodSpec as the single authority, but restore cached derived maps in stage0, or cache a keyed spec index and project from that. The source-of-truth refactor is good; the generated-Rust runtime shape is what regressed.

On invariant review more broadly:

• I do not see a new duplicate-authority violation in the .dag source; this PR removes one.
• I do not see a new fabrication fallback introduced here.
• I do see the stage0 repeated-scan issue above as a likely invariant violation under Performance / Facts Flow Forward.
• The shared emit helpers are good progress, but they are not full closure of the “emit consumes exact upstream facts” problem; the attached invariant notes still classify downstream semantic repair in emit as an invariant issue, so I’d treat this PR as progress, not end-state. INVARIANTS

For .dag compositional modeling quality, this is mostly strong:

• SimpleMethodSpec is a good product type and matches the existing HigherOrderMethodSpec style.
• expr_field_access_summary() and expr_method_call_semantics() are good accessor-layer additions. They let backends consume facts via accessors instead of re-matching ExprData themselves.
• The new shared helpers in 05_emit.dag are real 3→1 homomorphism progress.

My one modeling nit is operational: if the dominant downstream operation is “lookup by method name,” the authoritative authored shape can still be a list, but the runtime/emitter shape wants a cached keyed index. Right now the list is good source data but not a good direct lookup representation.

Roadmap alignment:

• TLC-2: I buy the narrow claim that the local Rust simple-method dual authority is gone.
• I do not buy the broader implication that runtime-bridge/signature-derivation is fully complete. The attached roadmap still has open bridge-fidelity work around partial_function_templates, CallableOf, and the collection-kind bridge. That makes “full lane complete” sound too strong. I’d either keep TLC-2 partial, or tighten the wording to something like “Rust simple-method wrapping/template authority unified.” ROADMAP
• Transport/config: I would not mark this complete from the code in this diff. Most of the substantive changes are shared expression emission and the SimpleMethodSpec refactor, not transport/config authority changes.

The other concrete code-review concern is emit_go_service_def. It changed from:

item.children |> filter(c => c.params |> count > 0)

to:

item.children

That is only safe if the post-dissolution model now guarantees that every service child is an operation node. If that invariant is true, I want a direct test proving it. If it is not true, this will mis-emit non-operation children as Go methods. This is the other source-level issue I’d want resolved before merge.

A few smaller notes:

• The new source_audit tests are useful guardrails, but they only prove parity between the spec list and the derived maps. They do not prove consumer behavior stayed correct.
• I’d add one direct behavior test for rust_runtime_bridge_wraps_collection_result_in_rc() and one Go service-emission fixture covering service children shape.
• The wraps_result parity test does not catch duplicate wraps_result: true entries in rust_simple_method_specs; it only checks membership, not uniqueness.
• emit_expr_field_access_shared takes target but doesn’t use it. Harmless, but dead parameter.

So: the refactor is directionally right, the .dag modeling is better after this PR, but I would not merge as-is. Fix the stage0 caching regression, justify or test the Go op_children = item.children assumption, and tone down the roadmap completion claim for transport/config (and probably TLC-2 wording as well).

---

View conversation

[briansrls]

Review (INVARIANTS: 0, MODELING: 2+/2-, ROADMAP: 2✓/1!)

MODELING — Strengths

• dsl/extdeps/languages/rust/emit.dag SimpleMethodSpec + derived helper functions (rust_method_templates(), rust_method_wraps_result()) tighten authority by making method template/wrapping metadata single-source within Rust extdep instead of parallel ad-hoc maps.
• src/v2/05_emit.dag The new shared expression helpers (emit_expr_*_shared, emit_typed_*_shared, extract_string_interp_parts) remove duplicated ExprData handling and keep target emitters focused on rendering, which improves compositionality and backend parity.

MODELING — Improvements

• dsl/extdeps/languages/rust/emit.dag method_name is still a string key, so this schema remains string-identity-based; define a shared method-template spec enum/family (including HigherOrderMethodSpec) to model dispatch structurally rather than by proxy names (M4/M7 direction).
• src/v2/05_emit.dag emit_typed_index_shared and emit_typed_slice_shared still require backend-specific recursion-depth threading from callers, so algebraic style facts are not yet fully normalized at the shared layer until depth policy is made an explicit shared strategy.

ROADMAP — Verified

• CG-2 TLC-2 Runtime bridge signature derivation: src/v2/05_emit_rust.dag and dsl/extdeps/languages/rust/emit.dag now consume rt_function_registry and SimpleMethodSpec-derived wraps in one pipeline, matching the roadmap claim that method wrapping is now from a single authority.
• CG-3 Transport/config: The PR updates service traversal and transport/type-template sharing points (service_fallback_transport, compute_service_fields, and corresponding emit paths), and roadmap text now marks this lane complete in this scope.

ROADMAP — Incomplete

• CG-3 3 backends → 1 parameterized homomorphism: Roadmap documents phases 1-3 only; code still has Go depth-asymmetry workarounds (depth = 0 in shared cast/index/slice paths), so full homomorphism is still blocked as stated.

This diff appears to close the previously flagged service traversal divergence and is mostly aligned with CG goals, with remaining gap explicitly limited to documented cross-backend depth/style asymmetry rather than new invariant violations.

[briansrls]

ChatGPT Review

I’d request changes before merge.

The core refactor is directionally right. In dsl/extdeps/languages/rust/emit.dag, replacing the two parallel simple-method maps with one SimpleMethodSpec authority is the right kind of move: it matches the repo’s “single authority, data-driven consumers” direction, and it avoids exactly the kind of bottom-up duplication the invariants call out. The new accessors in 00_core.dag (expr_field_access_summary, expr_method_call_semantics) and the shared helpers added to 05_emit.dag are also good compositional cleanup because they move more facts into shared accessors/helpers instead of making each backend rematch ExprData locally. Pasted text

INVARIANTS

My main blocker is the generated-Rust shape of that refactor. In the uploaded diff, src/v2/stage0/src/extdeps_languages_rust_emit.rs now caches rust_simple_method_specs() as a vector, but rust_method_templates() rebuilds a HashMap on every call, and rust_method_wraps_result() allocates/filter-folds a fresh HashMap on every call. rust_runtime_bridge_wraps_collection_result_in_rc() then calls rust_method_wraps_result() for lookup. That is a clear regression from cached indexed lookup to repeated rescan/rebuild. The attached INVARIANTS.md is explicit that repeated full rescans and “one scan turns into N scans” are design bugs, and that structural composition should exploit indexed O(1) lookup rather than linear scan. Keep SimpleMethodSpec as the authored authority, but restore cached derived maps or a cached keyed spec index in stage0. Pasted markdown

INVARIANTS

INVARIANTS

On invariant review more broadly: I do not see a new duplicate-authority violation in the .dag source; this PR removes one. I also do not see a new fabrication fallback. But I would not describe this as full closure of the emit-boundary problems yet. The attached invariants still classify emit-side semantic repair as an active violation pattern, and this PR improves that boundary without fully eliminating it. So I’d score this as progress, not completion, on the semantic-boundary front. INVARIANTS

Pasted markdown

For .dag modeling quality, SimpleMethodSpec is a good product type. It is a better model than two independent string-keyed maps, and it is consistent with the repo’s preference for authoritative data tables over scattered conditionals. My only modeling nit is that the runtime consumption pattern is still “lookup by method name,” so the authoritative authored shape can be a list, but the runtime/emitter shape wants a cached keyed index. I also agree with the roadmap note in the diff that SimpleMethodSpec and HigherOrderMethodSpec are now sibling schemas that likely want a shared MethodTemplateSpec eventually. That is not a blocker, just remaining model debt. INVARIANTS

Roadmap-wise, I buy the narrow TLC-2 claim in this PR: the local Rust simple-method dual authority is gone. I would keep that wording narrow, though. The broader algebra/bridge lane is still not fully done; the checked-in roadmap still carries open work around partial_function_templates, derivation cleanup, and dissolving the CollectionKind bridge. So “this local authority cleanup is complete” is fair; “the whole bridge/coercion lane is done” would be too strong. ROADMAP

I do not think the Transport/config checkbox should move to complete based on this diff. Most of the substantive code here is method-spec unification plus shared expression emission. The only transport-adjacent behavioral change I found is in Go service emission, where op_children changes from item.children |> filter(c => c.params |> count > 0) to item.children. That is only safe if service children are now guaranteed to be operations. Maybe that invariant is true now, but this diff does not prove it, and I did not see a new test locking it down. So that roadmap completion claim looks overstated from the code shown.

That Go change is my second concrete code-review concern. If any non-operation child can still appear under a service node, emit_go_service_def will now try to emit it as a method. At minimum I’d want a direct fixture proving the service-child shape after dissolution.

The new tests in src/v2/tests/src/source_audit.rs are useful as architectural ratchets, and INVARIANTS.md does allow narrow source-audit tests. But they are not enough on their own, and they are close to implementation-parity tests rather than consumer-behavior tests. I’d add one direct behavior test around rust_runtime_bridge_wraps_collection_result_in_rc() and one Go service-emission fixture. Also, method_wraps_result_derived_from_specs() checks membership parity but does not enforce uniqueness of wraps_result: true method names. INVARIANTS

A few smaller notes:

• emit_expr_field_access_shared takes target but does not use it.
• The stage0 rust_method_wraps_result() path allocates an intermediate filtered vector before folding; even aside from the caching issue, that is extra churn.
• The roadmap edits from 294/41 to 316/44 tests and from 9 to 2 hand-maintained files are status/reporting claims. I can’t validate those from the diff itself, so I’d rather see them backed by a verified run or split from the semantic refactor.

So my final take is: good source-model cleanup, good shared-emitter progress, but not merge-ready as-is. The stage0 lookup caching regression is the real blocker, the Go op_children = item.children assumption needs proof or a test, and the transport/config completion claim is not justified by the code in this PR.

---

View conversation

[briansrls]

ChatGPT review in progress... (view conversation)