@@ -3,7 +3,6 @@
 
 /hosting/godot-html5-template/ @dfinity/sdk
 /hosting/my_crypto_blog/ @dfinity/ninja-devs
-/hosting/photo-storage/ @dfinity/sdk
 /hosting/react/ @dfinity/ninja-devs
 /hosting/oisy-signer-demo/ @dfinity/ninja-devs
 /hosting/static-website/ @dfinity/sdk
 
@@ -222,7 +222,7 @@ Frontends use the `@dfinity/static-site` recipe (the certified-assets canister).
   ```
 - `_redirects` — SPA fallback so deep-link reloads don't 404: `/*  /index.html  200` (a `200` rewrite, not a redirect).
 
-Do **not** use `.ic-assets.json5` — that is the legacy asset-canister config; certified-assets ignores it (it gets served as a dead asset). No HSTS in the baseline: `_headers` apply in local dev too, and a canister-served `Strict-Transport-Security` would force HTTPS on `http://…localhost`. Consult the `static-site` skill before changing these (reserved-header list, `_headers` matches the asset key not the URL, etc.).
+Do **not** use `.ic-assets.json5` — that is the dfx-era asset-canister config; certified-assets ignores it (it gets served as a dead asset). Don't confuse the two canisters when reading source: the retired one is [`dfinity/sdk/src/canisters/frontend`](https://github.com/dfinity/sdk/tree/master/src/canisters/frontend) — whose crate is *also* called `ic-certified-assets` — while the one this repo uses is the separate [`dfinity/certified-assets`](https://github.com/dfinity/certified-assets) repo. No HSTS in the baseline: `_headers` apply in local dev too, and a canister-served `Strict-Transport-Security` would force HTTPS on `http://…localhost`. Consult the `static-site` skill before changing these (reserved-header list, `_headers` matches the asset key not the URL, etc.).
 
 ---
 
@@ -441,7 +441,7 @@ Rust: `icp build backend && candid-extractor target/wasm32-unknown-unknown/relea
 
 - **No canister factory.** The example must not create canisters at runtime (e.g. `actor class` sub-canisters, `create_canister` + `install_code`).
 - **At most 2 canisters in the `ic` environment.** Count the `ic` environment's canister list, not the local one (an example may deploy extra canisters locally — mock ledgers, pre-built infra — while restricting `ic` to `backend`+`frontend`). If a helper canister is only needed locally (e.g. a test subject, a mock ledger), restrict it to `local` via the `environments` block so `ic`/Ninja deploys only the real thing.
-- **Deployable in Ninja's no-terminal environment.** No custom build scripts beyond the standard recipe build; no controller-only setup step a Ninja user can't perform (e.g. `photo-storage` needs an `authorize` call from a controller, so it is excluded despite being a single canister).
+- **Deployable in Ninja's no-terminal environment.** No custom build scripts beyond the standard recipe build; no controller-only setup step a Ninja user can't perform (e.g. an `authorize` call that only a controller can make — such an example is excluded even if it is a single canister).
 - **Demonstrable, not just deployable.** A user must be able to do something meaningful with a *fresh* deploy — the core method returns a real result (compute, an HTTPS/inter-canister call, a CRUD round-trip, canister logs, a derived address/key), **or** the README gives a clear path to make it meaningful using resources the user can obtain themselves (II login, faucet **TESTICP**/**TESTICRC1** tokens, passing a canister principal). Exclude examples whose headline function returns nothing without state the user can't supply — e.g. `candid_type_generation`'s `list_neurons` returns only neurons the caller controls, which a fresh canister has none of, so it always comes back empty.
 
 For token examples, the `ic` environment should use the **TESTICP**/**TESTICRC1** test ledgers (not the real ICP ledger) so users can exercise transfers with free faucet tokens — and the README should point at the [faucet](https://faucet.internetcomputer.org) and the steps to use it.
 
@@ -2,7 +2,7 @@
 
 Frontend-only examples that run entirely on the Internet Computer — static sites, web apps, and game builds served on-chain with no custom backend. Each example is self-contained: follow its README to deploy it locally with `icp-cli`.
 
-These examples use the `@dfinity/static-site` recipe, which deploys the [certified-assets canister](https://github.com/dfinity/certified-assets) — the successor of the legacy [asset canister](https://docs.internetcomputer.org/guides/frontends/asset-canister) going forward, adding response certification, clean-URL canonicalization, and `_headers`/`_redirects` configuration. The one deliberate exception is [`photo-storage`](photo-storage/): it demonstrates programmatic uploads via `AssetManager`, an API only the legacy asset canister provides.
+These examples use the `@dfinity/static-site` recipe, which deploys the [certified-assets canister](https://github.com/dfinity/certified-assets) — the successor to the dfx-era asset canister, adding response certification, clean-URL canonicalization, and `_headers`/`_redirects` configuration.
 
 **New to ICP?** Start with [`static-website`](static-website/), the smallest possible deployment, then [`react`](react/) for a typical single-page app setup.
 
@@ -12,7 +12,6 @@ Prerequisites and dev-container setup are covered in the [repository README](../
 
 - [`static-website`](static-website/) — deploy a plain HTML/CSS website on ICP.
 - [`react`](react/) — a minimal React single-page application hosted fully on-chain.
-- [`photo-storage`](photo-storage/) — store and manage photos programmatically with `AssetManager` from `@icp-sdk/canisters/assets` (runs on the legacy asset canister).
 - [`godot-html5-template`](godot-html5-template/) — deploy a Godot HTML5 game build.
 - [`unity-webgl-template`](unity-webgl-template/) — deploy a Unity WebGL game build.
 - [`oisy-signer-demo`](oisy-signer-demo/) — connect to the OISY wallet signer, fetch token balances, and perform ICRC transfers.