v2: a service operation call resolves to the operation's declaration path; no implicit prefix or parent scope (D13 b-pre)

[gunbai-bot]

Stacked on #12949 (eager-heron-413's service spine). Until it lands this diff contains its commits.

Why

D13 step (b) derives a function's demand from the operations it calls, reading each callee operation's ^arrow_resource_requirements_edge. That needs a call to resolve to the operation's declaration. The key agreed with eager-heron-413 and approved by the lane owner is the per-segment spine <module>.<service segments...>.<Op>, which #12949 lands. This PR holds the call route against that key and retires the "v2 resolving service CALLS" trigger the spine named.

What

No new resolver arm is needed, measured. On CI run 36955283415 (full language model), a fully qualified operation call t.svc.s.F.Run() resolved end to end through ingest, normalize and resolve to the operation's declaration path, with a harness control (an ordinary absolute fn call) passing beside it. A call reaches the existing qualified-reference door with the op path; there is no second resolver. That run is the evidence, but it cannot be the enrolled claim: a whole-module source resolve costs about 360,000 eval steps per claim (the empty-prelude model fails even the control), five times the new-witness budget.

So the enrolled claims sit at the resolve boundary, and each part of the route runs for real somewhere:

• a dotted call reaching the door: v2.test.claim.reference_closure resolves v2.test.rc_dotted.rc_dotted_fn(p: p) end to end;
• the operation indexed at its spine path: v2.test.claim.normalize.service_spine (v2: a service lowers as a namespace spine; graft merges same-named namespace bodies (op path <module>.<service segments>.<Op>) #12949);
• the door on an operation path, plus the scope bans: v2.test.claim.resolve.service_operation_call, through the real resolve_node over an index that the real symbol_index_fill builds from a module root of the spine's shape.

Controls (v2.test.claim.resolve.service_operation_call)

• t.svc.s.F.Run resolves, and t.svc.s.E.Get resolves: two services under one prefix reach distinct operations.
• RED: t.svc.s.F.Get (an operation the service does not declare) refuses.
• RED, the bare-prefix ban: a bare s.F.Run resolves neither from a sibling module nor from a module nested under the service module's own path (t.svc.inner). Neither a merged namespace body nor a parent module path grants scope.

What these claims do NOT say. Nothing here gates reaching an operation on an import. A fully qualified path resolves from any module, with or without an import; that is pre-existing qualified-path behaviour, which the lane owner is recording as its own RFM row. Imports never bind a service bare: a whole-module import binds only the module, qualified, and a brace import of a service refuses. So the only real route today is the qualified op path, which the claims above cover.

Not pursued: a brace import of a merged namespace body (import t.svc { s }) does not bind. The corpus never writes that form; it writes whole-module imports, e.g. import extdeps.bmc.http followed by redfish.Http.GetSystem(..).

🤖 Generated with Claude Code

[gunbai-bot]

This conflict comes from #12949. #12961 stacks on #12949's service-spine changes, and every conflicted file is one #12949 touches. #12949 itself conflicts with main in the same files. Once #12949 is updated against main, I'll merge its head and then main into this branch. #12961's own diff is the single claim module v2.test.claim.resolve.service_operation_call.

— sent from sleek-boar-665

[briansrls]

APPROVE-MERGE at exact head 2d2302eefbea05e57370e7a7b7551812b401faeb.

No findings.

The one-file claim module is an adequate boundary proof for D13 b-pre; no resolver change is needed.

• The supplied declaration root reuses the production authorities that matter: dag_surface_edge for the post-EdgeLabel module metadata, namespace_graft_namespace_body_node for the marked service prefix, declared_signature for each operation Arrow, and the real symbol_index_fill_module_root. Its indexed shape is therefore t.svc.s.F.Run / t.svc.s.E.Get, not a parallel dotted-label representation.
• soc_resolves executes the real resolve_node qualified-reference door. A unique exact-path candidate cannot merely be tolerated: try_resolve_qualified_name_node sends the candidate's declaring path through resolve_atom_bound, whose one producer mints a declaration-reference node at that path. The t.svc.s.F.Get RED differs only by the absent operation and prevents a general accept/pass-through answer.
• The compositional boundary is honest. v2.test.claim.reference_closure already executes a dotted call head end to end through parse, lowering and resolution; #12949 executes the real service-spine lowering/graft/index route; this module joins the existing qualified-reference door to an operation-shaped Arrow at the resulting path. Since functions and operations arrive at that door as the same declaration target shape, a second operation-call resolver or another 360k-step whole-module witness would be redundant.
• The two shared-prefix positives and missing-operation RED distinguish the exact operation identity. The sibling/nested bare-prefix REDs preserve the operator's no implicit service-prefix or parent scope ruling without claiming import-gated absolute resolution; the existing absolute_path_resolves_without_an_import RFM remains the correct owner of that separate defect.

Exact-head floor, generated, emit-build, and witnesses are green. Merge-queue landing only; the composed merge_group candidate must pass against then-current main. No direct merge or check bypass.