docs: cover Canvas, Workflow, Gallery, and Model Manager features (#9196)

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

- New: Canvas Workflow Integration (run workflow on raster layer)
- New: Canvas Projects (.invk save/load)
- New: Custom Node Manager (install/manage community node packs)
- New: Layer tips (canvas drag & drop targets + lock transparency)
- gallery: virtual boards (by date)
- editor-interface: workflow library tags (dynamic per-user tags)
- adding-nodes: point manual install at Custom Node Manager
- models: editable source URL, bulk delete/reidentify, missing-files filter, settings export/import
- fp8-storage: hardware support tiers (Ampere / Ada+Hopper / pre-Ampere)

* docs: address review feedback

- custom-node-manager: fix broken creating-nodes link (absolute path)
- adding-nodes: fix broken community-nodes links (absolute path),
  document Workflow Connectors (#9027) under Connecting Nodes
- concepts/models: note that HF Repo IDs can be pasted into URL field,
  remove obsolete v4.0.0 autoimport tip
- fp8-storage: surface "full precision only" warning at the top,
  remove redundant quantized-formats bullet near the bottom

Author: Pfannkuchensack

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

@@ -33,14 +33,10 @@ Some models carry license terms that limit their use in commercial applications
 
 There are a few ways to install other models:
 
-- **URL or Local Path**: Provide the path to a model on your computer, or a direct link to the model. Some sites require you to use an API token to download models, which you can [set up in the config file].
+- **URL or Local Path**: Provide the path to a model on your computer, or a direct link to the model. Some sites require you to use an API token to download models, which you can [set up in the config file]. You can also paste a HuggingFace Repo ID here directly — it is detected and routed to the HuggingFace installer automatically.
 - **HuggingFace**: Paste a HF Repo ID to install it. If there are multiple models in the repo, you'll get a list to choose from. Repo IDs look like this: `XpucT/Deliberate`. There is a copy button on each repo to copy the ID.
 - **Scan Folder**: Scan a local folder for models. You can install all of the detected models in one click.
 
-:::tip[Autoimport]
-  The dedicated autoimport folder is removed as of v4.0.0. You can do the same thing on the **Scan Folder** tab - paste the folder you'd like to import from and then click `Install All`.
-:::
-
 ### Diffusers models in HF repo subfolders
 
 HuggingFace repos can be structured in any way. Some model authors include multiple models within the same folder.
@@ -54,3 +50,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

@@ -10,13 +10,33 @@ FP8 Storage cuts a model's VRAM footprint roughly in half by keeping weights on
 
 It pairs well with [Low-VRAM mode](/configuration/low-vram-mode/): low-VRAM mode streams layers between RAM and VRAM, while FP8 Storage shrinks the layers themselves.
 
+:::caution[For full precision models only]
+FP8 Storage only applies to **full precision** checkpoints (FP16 / BF16 / FP32). It is **silently a no-op** for already-quantized formats — **GGUF**, **NF4**, and **int8** checkpoints carry their own storage precision and the loader returns a different module type that the FP8 layer cast does not touch. If your model is already quantized, the toggle has no effect; use the full-precision variant of the model if you want to enable FP8 Storage.
+:::
+
 ## Requirements
 
 - **Nvidia GPU on Windows or Linux.** FP8 Storage uses CUDA tensor types and is silently disabled on CPU and MPS.
 - **CUDA 12.x and recent PyTorch.** The `float8_e4m3fn` dtype was added in PyTorch 2.1 — InvokeAI's bundled versions satisfy this.
 
 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:
@@ -64,10 +84,11 @@ That said, some artifacts have been reported on:
 
 If you see unexpected quality regressions, disable FP8 Storage on the affected model and re-run.
 
-## Combining with Low-VRAM mode and quantized models
+## Combining with Low-VRAM mode
+
+**FP8 + partial loading**: fully supported. FP8 Storage shrinks the layers; partial loading streams them between RAM and VRAM as needed. Use both on tight VRAM budgets.
 
-- **FP8 + partial loading**: fully supported. FP8 Storage shrinks the layers; partial loading streams them between RAM and VRAM as needed. Use both on tight VRAM budgets.
-- **FP8 + GGUF / NF4 / int8 quantized checkpoints**: these formats already have their own storage precision. FP8 Storage is not applied on top — the toggle is silently a no-op for quantized formats, since the loader returns a different module type.
+(For why FP8 Storage doesn't stack on top of GGUF / NF4 / int8 checkpoints, see the [callout at the top of this page](#for-full-precision-models-only).)
 
 ## Troubleshooting
 

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.