D13: requires clauses on the 14 product-layer service ops (1 Network, 4 opaque, 9 none)

[gunbai-bot]

14 product-layer service operations in dag/gunbc had no requires clause. An absent clause means Undecided, so any caller refuses. This PR audits them under the D13 rule:

clause	count	operations
requires Network	1	ntfy.Publish.PublishMessage (rest to ntfy.sh / tailnet HTTPS)
requires opaque	4	gunbc.Cli.Run, claim_executor.Executor.VerifyBuildArtifacts (runtime bin_path in argv[0]); sol_hold.ActivateHeld (runtime {ipmitool} path); owned_process.launch.LaunchOwned (runtime command)
requires none	9	sol_hold.ReleaseHeld (local kill); 8 transport-less pure folds in code_change_workflow, pr_digests, review_verdict

The 30 test/fixture operations without a clause stay undeclared on purpose: no test reads their demand. The doc lists them; a fixture gains a clause when a test needs one.

Route control and follow-up

approval_ntfy_deployment.dag imports std.resources { Network }, so the requires Network member binds. The route control is the generic pair in v2.test.claim.normalize.operation_requires_edge_test: a_requirement_naming_a_declared_resource_resolves_at_resolve_holds and a_requirement_naming_a_non_resource_refuses_at_resolve_RED. It runs the real resolve_node over an operation Arrow's requirements edge, on a synthetic module.

Follow-up (not done here): add a control specific to ntfy.Publish.PublishMessage that resolves the product module's import closure through v2, so its requirement is shown to resolve to std.resources.Network. No required lane resolves this module's requirement edge today: the head before the import was green with the name unbound.

🤖 Generated with Claude Code

[briansrls]

HOLD at exact head 20018dd8c75fc77735d4c431375ae2f2858c9a59.

P1 — PublishMessage authors an unbound resource requirement

dag/gunbc/auth/approval_ntfy_deployment.dag adds requires Network, but this head does not add import std.resources { Network }, and the module's existing imports do not bind Network.

That import is semantically required, not cosmetic. requires none and requires opaque are the two closed marker atoms that resolve carries unwalked; a named requirement is walked as a declaration reference and then checked to resolve to a declared resource. The D13 Network population in #12965 therefore added import std.resources { Network } in every module that received requires Network.

As written, the ntfy operation can parse and lower its requirements edge but will refuse once this product module reaches the resolve/census route, so it does not provide the declared Network fact to D13 step (b). The current green checks do not exercise that route for this module.

Please add import std.resources { Network } to approval_ntfy_deployment.dag and add or identify a positive route control establishing that ntfy.Publish.PublishMessage's requirement resolves to std.resources.Network rather than merely parsing. The other 13 classifications look correct: the four opaque rows execute caller-selected programs; ReleaseHeld is fixed local /proc/signal work; and the eight transportless rows are pure folds over supplied values.

Exact-head floor, generated, emit-build, and witnesses are green; this hold is semantic, not CI-related. No direct merge or check bypass.

[briansrls]

APPROVE-MERGE at exact head c3695b100c0cb6599329fe3e9810ac31a8b518bf.

This resolves my CHANGES_REQUESTED review 5396880727. No findings.

The one-commit delta supplies the missing import std.resources { Network } in approval_ntfy_deployment.dag; PublishMessage now authors the same bound resource identity used by the landed extdeps Network population rather than an unbound spelling.

The generic resolve pair is adequate evidence for this data-row correction. a_requirement_naming_a_declared_resource_resolves_at_resolve_holds and a_requirement_naming_a_non_resource_refuses_at_resolve_RED execute resolve_node over an operation Arrow carrying the requirements edge, differing on whether the target path is marked as a declared resource. Together they establish the exact semantic boundary this row relies on: a bound declared resource is admitted and a bound non-resource is refused. The commit also corrects the stale names in the test's authority comment; it does not weaken or replace the controls.

A full import-closure control specific to ntfy.Publish.PublishMessage would be useful integration evidence, but it is not required for every audited operation row and would test the broader product-module closure rather than a new behavior introduced here. The later demand-census/deletion route must still run at its own composed head and fail closed if this module cannot be observed; this approval does not pre-approve that census result.

The other 13 classifications remain unchanged from the otherwise-satisfactory held head. 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.