Incomplete static-site (certified-assets) migration: broken AssetManager example, dead .ic-assets.json5 configs, lost security headers

[marc0olo]

All frontends in this repo were switched to the @dfinity/static-site recipe (the certified-assets canister). That recipe swap was only step 1 of the migration: @dfinity/asset-canister and @dfinity/static-site are different canisters with different APIs and config mechanisms, not a rename. Audited against the migration requirements in dfinity/icskills#256 (static-site skill + references/migrating-from-asset-canister.md), the following gaps remain.

1. hosting/photo-storage is functionally broken

The example's core purpose — programmatic uploads via AssetManager from @icp-sdk/canisters/assets — cannot work against certified-assets, which does not expose the legacy store/create_batch/commit_batch/list API (confirmed by icskills#256, eval 3: "AssetManager doesn't work on static-site").

• src/App.jsx calls assetManager.list() (L56) and batch.store(...) (L75) → method-not-found at runtime.
• The README's authorize instruction coincidentally still resolves (certified-assets has a flat authorize(principal) model), which masks the breakage until an upload is attempted.

Decision needed: either (a) rework the example so photos are stored via a purpose-built backend canister (like rust/photo_gallery), (b) keep it deliberately on the legacy @dfinity/asset-canister recipe as a "programmatic uploads" example with a clear note, or (c) retire it. Uploads to certified-assets go exclusively through the recipe's sync plugin on icp deploy.

2. 18 dead .ic-assets.json5 files — including silently lost security headers

These files are ignored by certified-assets, yet still sit in public/ (or assets/), so they are uploaded and publicly served as regular assets:

hosting/oisy-signer-demo, motoko/ic-pos, motoko/vetkeys/{basic_bls_signing, basic_ibe, basic_vetkd, encrypted_notes_app_vetkd, password_manager, password_manager_with_metadata}, rust/image-classification, rust/photo_gallery, rust/qrcode, rust/vetkeys/{basic_bls_signing, basic_ibe, basic_timelock_ibe, basic_vetkd, encrypted_notes_app_vetkd, password_manager, password_manager_with_metadata}

The real damage is what these configs used to provide and certified-assets does not provide by default (it ships no default security headers):

• Explicit CSP + allow_raw_access: false lost in: oisy-signer-demo (hardened), image-classification, photo_gallery, qrcode, both vetkeys password_manager / password_manager_with_metadata (hardened CSP), both basic_vetkd (X-Frame-Options: DENY).
• security_policy: "standard" / "hardened" lost in the remaining files (ic-pos, other vetkeys apps) — there is no equivalent default; headers must now be written explicitly.

Required: delete every .ic-assets.json5 and port the security/caching headers to a _headers file per example (single-* pattern syntax, matched against the asset key). No _headers or _redirects file exists anywhere in the repo today.

3. SPA fallback unverified

None of the frontends ship a _redirects file (/* /index.html 200). The legacy enable_aliasing mechanism is gone. Any example using client-side routing with deep links will 404 on refresh. Each SPA-style frontend (ic-pos at minimum) should be checked and given a _redirects where needed.

4. Stale instructions and README/config drift

• native-apps/unity_ii_deeplink/README.md (×2, steps for assetlinks.json) instructs creating ii-bridge/public/.ic-assets.json5 with {"match": ".well-known/**", "allow_raw_access": true} — meaningless on certified-assets: there is no raw-access mode and .well-known/ is uploaded automatically. The .well-known/assetlinks.json serving path should be re-verified on the static-site canister and the instructions rewritten.
• hosting/static-website/README.md embeds an icp.yaml snippet still showing @dfinity/asset-canister@v2.1.0, while the actual icp.yaml uses @dfinity/static-site@v0.3.1.
• hosting/photo-storage/README.md describes the AssetManager flow (see item 1).

Suggested plan

1. Decide the fate of hosting/photo-storage (rework / legacy recipe / retire).
2. Repo-wide sweep: delete all .ic-assets.json5, add per-example _headers (porting existing CSPs; writing explicit headers where security_policy presets were used) and _redirects where the frontend needs SPA fallback.
3. Fix unity_ii_deeplink .well-known instructions and the static-website README snippet.
4. Afterwards, document the _headers/_redirects convention in AGENTS.md so new examples follow it.

Reference for all requirements: the static-site skill and its migrating-from-asset-canister.md in dfinity/icskills#256.

[marc0olo]

Split into actionable sub-issues (this issue stays as the umbrella / analysis record):

• hosting/photo-storage broken on static-site recipe — revert to asset-canister interim, decide long-term fate #1459 — hosting/photo-storage broken on static-site: interim revert to asset-canister, then decide rework/keep-legacy/retire
• Sweep: delete dead .ic-assets.json5, port security headers to _headers, add _redirects for SPAs #1460 — repo-wide sweep: delete 18 dead .ic-assets.json5, port security headers to _headers, add _redirects for SPAs, fix static-website README snippet, document convention in AGENTS.md
• unity_ii_deeplink: .well-known instructions invalid on static-site (certified-assets) #1461 — unity_ii_deeplink: rewrite .well-known / allow_raw_access instructions for certified-assets

Brokenness of photo-storage is now verified against the actual interface (certified-assets.did): no list/store/create_batch/commit_batch; mutations only via the single-session, plugin-version-locked start_sync/upload_chunks/execute_operations protocol — so a frontend rewrite against the new API is not a viable path for end-user uploads.