CliTool carries its ProgramIdentity (program-install lane PR 2)

[gunbai-bot]

PR 2 of the uniform program installation/access lane (node adhoc-573df38a-4f7; PR 1 was #12602).

What changes

• extdeps.tools CliTool carries program: ProgramIdentity instead of name: NonEmptyStr. The catalog row and the argv builders now name one declaration: the program the fleet probes for is the program it runs. This is the ruling from the lane manager: identity is a lower fact than acquisition, so CliTool is a row that carries the identity together with its installable_via.
• Cataloged identities for every catalog row. 17 rows had a literal or a string constant and no identity: grep, wc, nbdkit, sha512sum, rustfmt, npm, node, socat, sleep, jq, gh, websocat, gcloud, busybox, openssl, nfct, iptables-legacy-save. Each gets a fn <tool>_program() -> ProgramIdentity = cataloged_program(...) in its own module and an entry in cataloged_program's admit list.
• About 45 readers of CliTool.name move to .program.invocation, in extdeps, gunbc and the witnesses. No destructuring existed.
• Deleted dead code: extdeps.tools resolve, ResolvedTool and ResolveResult had no caller (the old note said so). Delete-first, because PR 3's host-program standing replaces what they would have been.
• Test rows point at production identities. host_cli_dependency_wet_witness_test's always-present probe row is now coreutils true (true_cli_tool), since no echo identity exists. Its witness function keeps its name because local_repo_wet_terminal and floor_route_gap enroll it by name.

Evidence

Every module that references CliTool, a *_cli_tool row or an identity function (4 chunks) was typechecked locally with the branch's gunbc. They are clean except for one refusal in gunbc.srv3_host_effect_apply (effect summary incomplete: calls into os_install_actuator_selection / nbd_proxy_virtual_media_install name no registry row). That refusal reproduces identically on a clean export of main, so it predates this PR.

Workaround, recorded

test.claim.tool_pin_witness and test.claim.tool_readiness_witness read a pin subject's program through a CliTool-typed helper, tool_invocation. Reading subj.program.invocation directly through the PinRefused { subject } binder typechecks and then fails at evaluation with error type cascade. The reduced shape is a generic fn whose type argument is inferred from its argument, then a two-level field read through the pattern binder; it reproduces with local types. It is filed as gunbc.recurring_failure_mode nested_field_read_through_a_binder_of_an_inferred_generic_result, and the helpers delete when that row climbs. neat-pike-685 confirmed it is not the optional-cardinality fix they are landing: their fixed build still fails on the reduction.

Residue and next

• cataloged_program still admits identity rows, not the CliTool rows themselves, so nothing forces a catalog row to exist for a cataloged identity. The module comment now states the two blockers: CliTool rows are data (gunbc.recurring_failure_mode admit_callers_names_no_caller_for_a_data_declaration), and extdeps.exec.command's builders sit below extdeps.tools.
• PR 3 adds the host-program standing and EnsureProgram together with their consumers: gunbc.host_cli_dependency's local probe and srv3_ensure_apt_tool's remote probe and apt install, under a subject-neutral name. The lane manager was told of this resequencing. PR 4 is verified artifacts; PR 5 is ntfy.

🤖 Generated with Claude Code