Bring back ICP Ninja buttons (icp-cli now supported) — eligibility audit, button convention, no BUILD.md

[marc0olo]

ICP Ninja now fully supports icp-cli projects, so the "Open in ICP Ninja" buttons removed during the dfx→icp-cli migration can come back. This issue covers the button restoration, the eligibility audit, and the BUILD.md question.

Eligibility audit

Hard requirements: no canister factories, max 2 canisters in the ic environment. Audited every icp.yaml (counting the ic environment's canisters: restriction where present):

Not eligible:

Example	Reason
motoko/canister_factory	canister factory (creates canisters at runtime)
motoko/ic-pos	4 canisters in ic (backend, frontend, ledger, index)
motoko/icrc2-swap	3 canisters in ic (swap, token_a, token_b)
rust/stake_neuron_from_cli	no canister at all — a CLI binary example
native-apps/unity_ii_deeplink	the example's substance is the Unity native app, which Ninja cannot exercise
wasm/counter	hand-written WAT — verify whether Ninja supports non-Motoko/Rust projects; exclude if not
hosting/photo-storage	on hold until #1459 is resolved (currently on the legacy asset-canister recipe)

Everything else is eligible — all remaining examples have ≤2 canisters in ic and no factories. Notably this includes evm_block_explorer and llm_chatbot (3 canisters total, but their environments block restricts ic to [backend, frontend]) and all 13 vetkeys examples (backend + frontend).

The ~45 examples already listed in .github/workflows/ninja_pr_checks.yml are the Ninja-synced baseline; the eligible-but-unsynced remainder can be proposed to the Ninja team as additions.

Button format and placement

Historical format (pre-migration): To open this project in ICP Ninja, click [here](https://next-icp.ninja/i?url=https://github.com/dfinity/examples/tree/master/<lang>/<example>) — note the staging host. Before rollout:

1. Confirm the production import URL format and the official button/badge asset with the Ninja team.
2. Standardize placement: one line/badge directly under the H1, before the intro paragraph, identical across all examples.
3. Check whether Ninja still consumes README YAML frontmatter (keywords: [...] existed pre-migration, e.g. old hosting/my_crypto_blog) and either restore it consistently or drop it everywhere.
4. Document the button convention (and the eligibility rules) in AGENTS.md's README section so new examples apply it correctly.

BUILD.md: recommendation — do NOT bring it back

The historical BUILD.md was a per-example copy of the same generic "Continue building locally" guide for users downloading a project from Ninja: install dfx/Node/Rust/mops, then deploy. Judgment:

1. It was duplicated boilerplate (dozens of near-identical copies) that went stale as a unit — the last version still instructs installing dfx.
2. Its audience is Ninja users at download time, not repo visitors. That content belongs on the Ninja side (injected into the download bundle or shown in the UI) or on a single docs page — not as N committed copies here.
3. Under icp-cli, the "continue locally" story is each README's "Build and deploy from the command line" section. A second doc with the same commands guarantees drift.

If Ninja requires an in-project "continue locally" document, ask the Ninja team to inject it at download time (they control the tooling instructions and can keep them current), or have the button section link to the README's build section.

Suggested plan

• Confirm production button URL/asset + frontmatter requirements with the Ninja team
• Add the button to all eligible examples (start with the ninja_pr_checks.yml set; both language variants of a pair)
• Propose eligible-but-unsynced examples to the Ninja team
• Document button convention + eligibility rules in AGENTS.md
• Keep BUILD.md out (see above); revisit only if the Ninja team cannot inject download-time docs

[marc0olo]

Corrections to the eligibility audit (thanks @marcowalz for catching the ic-pos error):

1. motoko/ic-pos IS eligible. The audit script had a parsing bug: its regex located the ic environment block by prefix-matching - name: ic, which latched onto - name: icrc1_ledger instead — so it never saw the actual ic environment's canisters: [backend, frontend] restriction and counted all 4 canisters. The manifest deploys exactly 2 canisters on ic (ledger/index principals are injected as env vars pointing at TICRC1), and mainnet is a plain icp deploy -e ic. Removed from the ineligible list.

2. hosting/photo-storage is eligible by the two hard rules (1 canister, no factory) — but should still not get a Ninja button, for a different reason than originally stated: the upload flow requires a controller to run icp canister call frontend authorize '(principal ...)' before anyone can upload, and a Ninja user has no way to perform a controller call on the deployed canister. The example would deploy fine but its core feature would be unusable in Ninja.

3. composite_query (both languages) is NOT eligible — missed in the original audit. It creates bucket canisters at runtime: Motoko spawns actor class Bucket sub-canisters; Rust calls create_canister_with_extra_cycles + install_code. That's a canister factory under the hard rules (consistent with its absence from ninja_pr_checks.yml, and with its icp deploy --cycles requirement).

4. Side observation: ninja_pr_checks.yml contains a stale path entry motoko/classes/** — no such example exists in the repo. Worth removing when the workflow is next touched.

Corrected ineligible list: motoko/canister_factory (factory), motoko+rust/composite_query (factory), motoko/icrc2-swap (3 canisters on ic, local-only pre-built ledgers), rust/stake_neuron_from_cli (no canister), native-apps/unity_ii_deeplink (substance is the native app), wasm/counter (WAT — verify Ninja support), hosting/photo-storage (controller-only authorize prerequisite). Everything else — now including motoko/ic-pos — meets the hard requirements.