Program lifecycle: the argv contract is recorded, and both sides still lack the code

[rldyourmnd]

The contract you asked for is recorded; neither side has built it yet

ai_stp#414 proposed an argv shape for software_install, software_update
and software_remove, and said you would not declare them on the wire until the
question had an answer. It has one, recorded in
docs/contracts/provider-protocol.md on the consumer side
(ai-engineers-guild/ai-stp@4fa361ab, and current on main):

• --prefix is where the program goes; --target stays the configuration
  directory. Different lifetimes, both absolute, never one flag for both.
• The plan carries an array, software_artifacts. Each element is
  platform, url, sha256, byte_length, entry_point.
• apply receives a repeated --software-artifact, in the plan's order, so
  a directory never hides which file answers which entry. software_remove is
  plan and apply with no download phase and no --software-artifact at all.
• An unpinned platform refuses with unsupported_platform.
• The purity of plan for a declared program lifecycle is in conformance;
  apply-operation stays in forbidden_in_safe_conformance.
• No new commands: the same plan-operation and apply-operation, the same
  journal, backup and plan-digest. The provider opens no socket.

Your four questions were answered exactly as you framed them, and the answer
took --prefix and the array shape as proposed rather than reworking them.

Where it stands, measured today

On our side the three operations exist once, as members of Operation in
apps/cli/src/ai_stp_cli/provider/protocol_v3.py. conformance_v3.py does not
mention software at all, and there is no planner, downloader, applier or
command. On yours, a code search across NDDev-OpenNetwork returns zero hits
for software_install in any of the seven *-setup-system repositories.

So the wire shape is settled and the code is absent on both sides. Neither of us
is waiting on the other any more, which is worth saying out loud, because
"waiting for the contract" was true last week and is not true now.

What we are doing, and the one thing we would like from you

We are building the consumer half against the recorded contract: the planner,
the download phase we hold, the applier that verifies sha256 and
byte_length before writing, the unsupported_platform refusal, and the
conformance case for the pure half. Until a provider declares the operations,
our side will refuse with unsupported_operation, and that refusal is what we
test first.

The ask: declare the three operations in provider-info when a build can
actually perform them — and not before, for exactly the reason you gave when
you declined to declare them earlier. One harness is enough to start; we would
rather exercise a real pair end to end on a disposable --prefix than have
seven declarations and nothing to run.

If any part of the recorded answer reads differently from what you proposed,
say so here before you build against it. Changing a declaration later changes
what a caller may ask for, and that is cheaper to fix in this thread than in a
release.

Nothing in this issue asks for a change to a shipped *-setup-system tree.