docs: cover Canvas, Workflow, Gallery, and Model Manager features

docs/src/content/docs/concepts/models.mdx

@@ -54,3 +54,65 @@ In this situation, you may need to provide some additional information to identi
 :::
 
 [set up in the config file]: ../../configuration/invokeai-yaml
+
+## Editing model metadata
+
+Every model has an editable **Source URL** field alongside its name and description. Use it to record where a model came from — for example a Civitai or HuggingFace page — independent of how it was originally installed. The URL is editable from the model's **Edit** view and appears as a clickable link in the model header once set. Models without a URL simply hide the field.
+
+This is purely metadata: the URL has no effect on loading and is not used to refresh or reinstall the model. It is mainly useful for going back to the model's documentation, license, or example prompts later.
+
+## Bulk actions in the Model Manager
+
+The Model Manager supports multi-selection for batch operations.
+
+- **Select multiple models** by clicking with **Ctrl** (Windows / Linux) or **Cmd** (macOS) held, or by using the checkboxes on each row. A sticky header at the top shows the current selection count and is always visible while you scroll.
+- Open the **Actions** dropdown for the selection. The available actions are:
+  - **Delete Models** — removes every selected model in a single confirmation step. Partial failures (e.g. permission issues) are reported per-model in the result toast.
+  - **Reidentify Models** — re-probes every selected model, updating fields that depend on the file contents (type, base, format, variant, etc.). This is the bulk version of the per-model reidentify action.
+
+:::caution[Reidentify resets custom settings]
+Reidentifying a model re-derives its configuration from the file on disk. Any custom settings you've adjusted on those models — default settings, descriptions, trigger phrases — may be overwritten. The confirmation modal warns you about this before running.
+:::
+
+Both actions handle partial failures: if some models succeed and others fail, the toast lists succeeded and failed counts and the list view updates immediately for the ones that worked.
+
+## Finding orphaned models
+
+If a model file is deleted or moved outside the Model Manager, its database entry sticks around. To find these orphaned entries:
+
+1. Open the Model Manager.
+2. Open the **type filter** dropdown and pick **Missing Files**.
+3. The list now shows only models whose files are no longer present on disk. Each one also displays a **Missing Files** badge in its row.
+
+Orphaned models are automatically excluded from selection dropdowns (main model, LoRA, VAE, etc.), so you cannot accidentally pick one for generation. Use the [bulk delete action](#bulk-actions-in-the-model-manager) to clean them out in one step.
+
+## Exporting and Importing Model Settings
+
+Each installed model has an **Export Settings** and **Import Settings** action in the Model Manager. Use these to back up a model's configuration, move it to another install, or share a curated setup with someone else.
+
+### What gets exported
+
+The exported `.json` file captures the configuration you have set on the model, not the model weights themselves:
+
+- `default_settings` — steps, CFG / guidance, scheduler, dimensions, FP8 storage toggle, VAE precision, etc.
+- `trigger_phrases` — for LoRAs and similar.
+- `cpu_only` — for encoder-type models.
+- `name`, `description`, `source_url` — the model's identifying metadata.
+- `cover_image` — the model's thumbnail, embedded as a base64 data URL.
+
+Fields you have not set are omitted from the file. The format is forward and backward compatible: older clients ignore newer fields, and a file produced by a newer version still imports cleanly into an older one (it just skips the fields it does not understand).
+
+### Importing
+
+Importing applies the JSON to the currently selected model:
+
+- `default_settings`, `trigger_phrases`, `cpu_only`, `name`, `description`, and `source_url` are applied via the normal model update path. Any field that the target model type does not support (e.g. `cpu_only` on a model that has no such setting) is listed in a "skipped" toast — everything else still applies.
+- `cover_image` is uploaded and set as the model's thumbnail.
+
+Imports are validated before they run. The file is rejected if `source_url` is not an `http(s)://` URL or if `cover_image` is not a valid image data URL — so a malformed or hand-edited file cannot quietly poison a model's configuration.
+
+### Typical workflows
+
+- **Back up a model you've spent time tuning** so you can restore its settings after a reinstall, or roll back after experimenting.
+- **Copy settings between two installs of the same model** — e.g. between a desktop and a workstation.
+- **Share a curated setup** (name, description, thumbnail, default steps / CFG / scheduler, trigger phrases) for a model you have configured well.

docs/src/content/docs/configuration/fp8-storage.mdx

@@ -17,6 +17,22 @@ It pairs well with [Low-VRAM mode](/configuration/low-vram-mode/): low-VRAM mode
 
 There is no hardware requirement for FP8 *compute* — InvokeAI casts back to FP16/BF16 for math. This means FP8 Storage works on GPUs that do not natively support FP8 matmul (e.g. RTX 30-series), at a small per-step throughput cost.
 
+## Hardware support tiers
+
+Because InvokeAI's FP8 path uses `enable_layerwise_casting` — storage in FP8, compute in BF16/FP16 — the practical benefit of toggling FP8 Storage depends on what your GPU can do natively. There are three tiers:
+
+### RTX 30-series and older Ampere workstation cards — VRAM win only
+
+The toggle works as advertised: the UNet / transformer drops by roughly 50% on the GPU. Per-step latency is the same or marginally slower because every forward pass adds an FP8 → BF16 cast on entry and a BF16 → FP8 cast on exit. This is the **largest target group**: 3090 owners squeezing FLUX into 24 GB benefit the most.
+
+### RTX 40-series, RTX 50-series, and Hopper — VRAM win today, compute win possible later
+
+These GPUs have native FP8 tensor cores. The toggle still buys you the same ~50% VRAM reduction today, because the forward pass still runs in BF16 under `enable_layerwise_casting`. If InvokeAI later wires up a true FP8 matmul path (e.g. via `torchao`), the same toggle will *also* unlock compute speedups on this hardware. Until then, treat the benefit as "VRAM only, same as Ampere".
+
+### Pre-Ampere Nvidia, MPS, and CPU — no-op
+
+FP8 Storage is silently disabled on anything that is not CUDA, and it is not meaningful on pre-Ampere CUDA cards either. On CPU PyTorch *technically* supports FP8 dtypes, but the cast operations are software-emulated and end up costing more than the memory savings buy back, so InvokeAI does not apply FP8 Storage on CPU. If you toggle it on unsupported hardware, the loader logs nothing and returns the model unchanged — the UI may also grey the toggle out or show a "not supported on this hardware" note.
+
 ## Enabling FP8 Storage
 
 FP8 Storage is a **per-model setting**, configured from the Model Manager:

docs/src/content/docs/features/Canvas/canvas-projects.mdx

@@ -0,0 +1,57 @@
+---
+title: Canvas Projects (.invk files)
+sidebar:
+  order: 4
+---
+
+import { Steps } from '@astrojs/starlight/components';
+
+Canvas Projects let you save the entire state of a canvas — including all layers, masks, reference images, generation parameters, and LoRAs — into a single `.invk` file that you can reopen later or share with someone else.
+
+`.invk` files are ZIP archives. They embed the actual image bytes for every layer and reference image, so a project is fully self-contained: opening it on another machine or after wiping the gallery still restores everything.
+
+## Saving a project
+
+<Steps>
+1. Open the canvas and arrange your layers, masks, reference images, and parameters the way you want them.
+2. From the menu, choose **File → Save Canvas Project**.
+3. Optionally rename the project (the default is **Canvas Project**).
+4. Save the `.invk` file to disk.
+</Steps>
+
+What gets saved:
+
+- All raster, inpaint, and control layers, with their image data, transforms, opacity, and lock state.
+- All masks.
+- Reference images.
+- Currently configured generation parameters (model, prompts, scheduler, seed, dimensions, etc.).
+- LoRAs and their weights.
+
+## Loading a project
+
+<Steps>
+1. From the menu, choose **File → Load Canvas Project**.
+2. Pick the `.invk` file.
+</Steps>
+
+When a project is loaded, the canvas is replaced with the project's state. LoRAs are reset first, then re-applied from the project, so opening a project never leaves stale LoRAs from your previous session attached.
+
+### Image deduplication
+
+Loading a project does **not** blindly re-upload every embedded image. Invoke compares each embedded image against what is already in your gallery and only uploads the images that are missing. Re-opening the same project a second time, or opening it shortly after saving it, is therefore very fast — most or all images will already be on the server.
+
+This also means a project shared with another user will upload all its images the first time it is opened on that user's machine, then become nearly free to re-open after that.
+
+To keep the gallery responsive during large imports, image fetches and uploads are limited to a small number of concurrent requests.
+
+## What `.invk` does *not* save
+
+A `.invk` file is a canvas state snapshot. It does **not** contain:
+
+- The models, LoRAs, or embeddings themselves — only references to them. If you share a project, the recipient needs the same models installed (or compatible substitutes).
+- Workflow editor state (use **Save Workflow** in the workflow editor for that).
+- Gallery boards or images outside the canvas.
+
+## Sharing projects
+
+`.invk` files are safe to share directly. The recipient drops the file via **File → Load Canvas Project** on their own canvas. They'll need any referenced models / LoRAs installed locally; if a referenced model is missing, the parameter slot will be empty and they can pick a substitute before generating.

docs/src/content/docs/features/Canvas/layers-and-drops.mdx

@@ -0,0 +1,35 @@
+---
+title: Layer Tips
+sidebar:
+  order: 6
+---
+
+A couple of layer-related behaviors that aren't obvious from the canvas UI alone.
+
+## Drag & drop targets
+
+Dragging an image onto the canvas reveals **five** drop zones, arranged as two zones on top and three on the bottom:
+
+| Top row | |
+| :--- | :--- |
+| **New Raster Layer** | Create a regular raster layer from the dropped image. |
+| **New Control Layer** | Create a control layer from the dropped image. |
+
+| Bottom row | |
+| :--- | :--- |
+| **New Regional Reference** | Use the image as a regional reference. |
+| **New Inpaint Mask** | Create a new inpaint mask layer using the image as the mask source. |
+| **New Resized Control Layer** | Create a control layer resized to the current canvas dimensions. |
+
+You can drop from the gallery, from disk, or from any panel that shows a draggable image.
+
+## Lock transparency on raster layers
+
+Each raster layer has a **Lock Transparency** toggle (drop icon) in its layer header. When enabled, brush strokes only affect existing non-transparent pixels — painting over transparent areas does nothing. This behaves like Photoshop's "Lock Transparent Pixels".
+
+Typical uses:
+
+- **Recolor an existing shape** without bleeding paint into the empty space around it.
+- **Refine details on a subject** that was painted on an otherwise transparent layer, with no risk of growing its silhouette.
+
+Toggle it off to resume normal painting. The lock is per-layer, so different layers can be locked or unlocked independently. Pressure-sensitive pen input and undo/redo both respect the lock.

docs/src/content/docs/features/Canvas/run-workflow.mdx

@@ -0,0 +1,70 @@
+---
+title: Run Workflow on Canvas
+sidebar:
+  order: 5
+---
+
+import { Steps } from '@astrojs/starlight/components';
+
+You can run any workflow against a raster layer directly from the canvas. The selected layer is passed in as the workflow's image input, and the results land in the canvas staging area where you can review and accept them — without leaving the canvas tab.
+
+## Requirements for a workflow
+
+For a workflow to be available from the canvas, it must satisfy three conditions:
+
+1. **Form Builder is enabled.** The workflow's parameters are presented through the Form Builder UI when the workflow is launched from the canvas, so the workflow needs to have a form configured.
+2. **At least one image input field.** The layer you right-click on is passed into the first eligible image field as the workflow's input.
+3. **At least one `Canvas Output` node.** This is the node that marks which images should be routed back to the canvas staging area.
+
+Workflows that do not meet all three are filtered out of the canvas workflow selector.
+
+## The `Canvas Output` node
+
+`Canvas Output` is a dedicated workflow node that explicitly marks the images you want shown in the canvas staging area. Add it at the end of any branch whose output should appear on the canvas.
+
+A workflow can include **multiple `Canvas Output` nodes**. Each one becomes its own entry in the staging area, with an individually selectable thumbnail. You can navigate between entries with the arrow keys and accept just one of them onto the canvas.
+
+:::note[Why an explicit node?]
+Earlier versions detected output images heuristically (by scanning for `board` fields). That was fragile and caused unrelated nodes — for example, `save_image` — to be mistaken for canvas outputs. `Canvas Output` makes the routing intentional.
+:::
+
+## Running a workflow
+
+<Steps>
+1. On the canvas, **right-click a raster layer** to open its context menu.
+2. Choose **Run Workflow**.
+3. Pick a workflow from the list. Only workflows that meet the [requirements](#requirements-for-a-workflow) appear here.
+4. Adjust any exposed parameters in the form. All form field types are supported: text, numbers, booleans, enums, schedulers, boards, models, and images.
+5. Click **Run**. The workflow is queued and the results stream into the staging area as they complete.
+</Steps>
+
+The current layer is automatically passed into the workflow's image input — you do not need to select an image manually.
+
+## Reviewing and accepting results
+
+Results appear in the canvas staging area strip at the bottom of the canvas:
+
+- If the workflow has a single `Canvas Output`, you get one thumbnail per run.
+- If it has multiple `Canvas Output` nodes, each run produces multiple thumbnails, one per output node.
+- Use the staging area's next / previous controls (or arrow keys) to cycle through entries. Navigation wraps across run boundaries.
+- Click **Accept** to commit the currently selected entry onto the canvas. Only that single image is committed — siblings stay in staging until you accept or discard them.
+
+## Troubleshooting
+
+### My workflow doesn't appear in the selector
+
+Check, in order:
+
+- The workflow has Form Builder enabled.
+- The workflow has at least one image input field.
+- The workflow contains at least one `Canvas Output` node.
+
+If any of these is missing, the workflow is hidden.
+
+### Queueing fails with a "BoardField" validation error
+
+This was a known issue with workflows that combined `save_image` and `canvas_output` nodes. It is fixed — update Invoke and try again.
+
+### Errors during execution
+
+Workflow errors are surfaced as toasts and the staging area is cleaned up so it returns to a usable state. Open the queue panel for the full error message.

docs/src/content/docs/features/Workflows/adding-nodes.mdx

@@ -133,16 +133,18 @@ Custom names you set on input fields will carry over into the Linear View.
 
 InvokeAI's node system is extensible. Community-created nodes can add new capabilities to your workflows — from specialized image processing to LLM-powered prompt generation.
 
-To install a community node pack:
+The easiest way to install a community node pack is through the **[Custom Node Manager](./custom-node-manager)**: paste a Git URL in the **Nodes** sidebar tab and the pack is cloned, loaded, and made available without a restart.
+
+If you prefer to install manually:
 
 <Steps>
-1. Find a node pack from the [Community Nodes](../community-nodes) list.
+1. Find a node pack from the [Community Nodes](./community-nodes) list.
 2. Clone or download the node pack into the `nodes` folder inside your InvokeAI installation directory.
-3. Restart InvokeAI. The new nodes will appear in the node picker.
+3. In the Custom Node Manager, click **Reload** (or restart InvokeAI). The new nodes will appear in the node picker.
 </Steps>
 
 :::note
-The recommended method is `git clone`, which makes it easy to update node packs later with `git pull`.
+`git clone` is preferred over downloading a ZIP — it makes it easy to update node packs later with `git pull`.
 :::
 
-For more details and a full catalog of available community nodes, see the [Community Nodes](../community-nodes) page.
+For more details and a full catalog of available community nodes, see the [Community Nodes](./community-nodes) page.