cloud-engine-canisters: outcall guidance names a removed ic-cdk API, and flags ic-cdk-management-canister as unusable

skills/cloud-engine-canisters/SKILL.md names ic_cdk::management_canister::http_request for HTTPS outcalls in three places, and separately lists ic-cdk-management-canister among helper libraries that "do not work here". Both were fine until #387; together with that PR they now point an agent at a pitfall the same skill warns about.

None of the engine rules change. This is a naming and scoping fix.

Problem A — the Rust outcall API was removed in ic-cdk 0.20

Line	Context
38	"Management-canister calls keep their standard wrapper"
84	"Keep the wrapper; never swap in a hardcoded fee"
272	Pitfall 3, "Rewriting outcall code for an engine"

All three name ic_cdk::management_canister::http_request. That module was removed in ic-cdk 0.20. It is not wrong for this skill as written — compatibility: declares ic-cdk >= 0.18, and the call exists on 0.18/0.19 — but it is the only Rust path offered, so a project on 0.20+ has none.

Problem B — ic-cdk-management-canister is flagged unusable, but is now the recommended outcall path

L169 and pitfall 10 both say:

The helper libraries do not work here. ic-vetkeys, ic-cdk-management-canister, and Motoko's mo:ic-vetkeys/ManagementCanister all call aaaaa-aa directly and attach the fee for you. On an engine that is a cross-subnet, cycle-bearing call: rejected twice over (Rules 1 and 2).

That reasoning is sound for the chain-key methods — sign_with_ecdsa, vetkd_derive_key and friends target another subnet and charge real cycles, so they must go through the proxy. But the sentence names the whole crate, and as of #387 ic-cdk-management-canister 0.2 is exactly what https-outcalls now tells Rust callers to use for http_request.

An agent holding both skills reads:

• https-outcalls: use ic-cdk-management-canister 0.2's HttpRequest::send()
• cloud-engine-canisters: ic-cdk-management-canister does not work here, relay through the proxy

and can conclude outcalls must be hand-encoded through the proxy on an engine. That is pitfall 4 of this very skill ("proxied outcall fails consensus", no transform applies) and Rule 3 says the opposite.

The distinction the wording loses is the one the rules are built on — where the target lives, not whether cycles are involved:

├─ local subnet (aaaaa-aa http_request)
│    free cost schedule, ic0.cost_* returns 0, nothing to attach
│    └─ ordinary wrapper, no proxy                      (Rule 3)
└─ another subnet (XRC, ECDSA/Schnorr, vetKD)
     charges real cycles the engine cannot pay, and the protocol
     rejects cross-subnet cycle-bearing calls from CloudEngine
     └─ cycles ride in ProxyArgs.cycles                 (Rule 4)

Why this surfaced now

Before #387, https-outcalls pointed at ic_cdk::management_canister::http_request — inside ic-cdk, a different name — so there was no collision. #387 moves Rust outcalls to the standalone crate, and the two skills now name the same crate with opposite advice.

The underlying rule is unchanged

Worth stating explicitly so the fix does not drift into the rules: outcalls are still free on an engine under pay-as-you-go pricing. dfinity/ic has a test total_fee_is_zero_on_a_free_subnet asserting fee.real() == Cycles::zero() for a fully replicated version 2 outcall on a CanisterCyclesCostSchedule::Free subnet (rs/https_outcalls/pricing/src/fees.rs). Rule 3 holds as written; only the API name and the crate-level warning need adjusting.

Suggested fix

1. Update the three Rust mentions to the 0.2 builder, keeping a fallback for older crate lines. https-outcalls already frames this as three dependency worlds; mirroring that phrasing keeps the two skills consistent.
2. Scope the helper-library warning to the chain-key helpers rather than the crate — e.g. "ic-cdk-management-canister's chain-key helpers" — and say explicitly that its HTTPS-outcall builders are fine and are the supported path, per Rule 3.
3. Revisit compatibility: (ic-cdk >= 0.18) if the examples move to the 0.2 builder, which requires ic-cdk >= 0.20.3.

Evals

evaluations/cloud-engine-canisters.json has 9 cases, including "HTTPS outcall from an engine canister" and "Adversarial: reaching for a chain-key helper library on an engine". Neither covers this trap, because it only exists once both skills are in play. Suggested case:

Can I use ic-cdk-management-canister for an HTTPS outcall from a cloud engine canister?

expecting: yes for http_request (local, zero cost, ordinary wrapper); no for the chain-key methods (cross-subnet and cycle-bearing, relay through the proxy); and never routing the outcall through the proxy.

Related

#366 proposes a version-coherence guard so skills cannot contradict each other on dependency versions. This is the same failure class one level up — two skills agreeing on the version of a crate while disagreeing on whether you may use it — so a version checker would not catch it. Worth noting there as a second category rather than expanding that issue's scope.

Found while reviewing #387; out of scope for that PR.

Start with skills/cloud-engine-canisters/SKILL.md at the cited lines and compare its Rust outcall guidance with the https-outcalls skill. Check evaluations/cloud-engine-canisters.json for the related cases. Done means the Rust API references, compatibility range, and helper-library warning consistently distinguish HTTPS outcalls from chain-key helpers without changing the engine rules.