fix(icp-cli, caffeine-app): carve out the one real dfx exception

[raymondk]

Closes #282

sns-launch is right; the absolutist claim is wrong

icp-cli:14 said "Never use dfx — always use icp", and pitfall 1 said "All commands have icp equivalents". sns-launch then requires dfx sns. I checked the installed CLI rather than assuming which side was wrong — icp 1.2.0 top-level subcommands:

build  canister  cycles  deploy  environment  identity
network  new  project  settings  sync  token  help

No sns, nns, governance or proposal. So "all commands have icp equivalents" is false, and sns-launch's use of dfx sns is a genuine gap in icp, not a skill error.

Both places now name the exception and point at sns-launch. The anti-dfx rule is untouched for build, deploy, canister, identity and cycles work — which is what it's actually for.

caffeine-app: the claim is true, the template needed context

"There is no dfx in the workflow" is accurate in the sense that matters — you never invoke it. But references/frontend-template.md branches on DFX_NETWORK, exposes DFX_/CANISTER_ env prefixes, and proxies /api to 127.0.0.1:4943, which is dfx's replica port (icp-cli uses 8000 — icp-cli/references/dfx-migration.md even says to search for 4943 and expect zero matches, though that guidance is for icp-cli projects, not Caffeine ones, so it isn't strictly a contradiction).

Added a note where the config appears: these are inherited scaffold naming conventions, not a dfx dependency, and the proxy only does something if a replica is actually serving on 4943.

What I deliberately did not do: call the 4943 target wrong. Verifying what Caffeine's own dev server serves on needs a caffeine.ai account I don't have, so asserting it would be a guess dressed as a fix.

Regression check

The rule I softened is exactly what one eval case covers, so I re-ran it:

Case	Result
icp-cli 10 — "Adversarial: dfx commands"	4/4, unchanged

The model still corrects dfx deploy --network ic → icp deploy -e ic and does not endorse dfx. The carve-out didn't leak into deploy advice.

Pre-existing eval failure, not from this PR

While checking, I found icp-cli case 3 "Migrate from dfx" scores 5/6 — and I verified it scores 5/6 on unmodified main too, so it is not a regression from this change. The failing behavior:

Asset canister uses @dfinity/asset-canister recipe with a version pin
→ The frontend canister in the actual icp.yaml uses @dfinity/static-site@v0.3.3 as the recommended recipe; @dfinity/asset-canister@v2.2.1 is only mentioned as an alternative in prose.

The model is following the skill: icp-cli:105 recommends @dfinity/static-site@v0.3.3 as the frontend recipe. The eval expectation looks stale rather than the skill being wrong — it probably should accept static-site. I've left it alone since it's unrelated to this issue and changing an eval's expectations is a judgement call for a maintainer, but it's worth a follow-up.

npm run validate passes: 26 skills validated, all passed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NEm1Tbkypzi8SuXhrMfBek

[github-actions]

Skill Validation Report

Project Checks

✓ Project checks passed for 2 skills (0 warnings)