Neutral wording in import docs; portable tool output paths

Import-surface docs and docstrings describe the automation as a
migration script; status-doc references in CHANGELOG/ADR-009/ROADMAP
point at repo files. Screenshot/verify tools write to /tmp/shopdb-shots
(created on import) instead of a machine-specific directory.

docs/IMPORT-API.md

@@ -6,7 +6,7 @@ API. No direct writes to the `shopdb_flask` database are needed or wanted: every
 row is created through a documented endpoint so authorization, validation,
 auditing, and plugin hooks all run exactly as they do for a human operator.
 
-An LLM or a plain Python script can run the whole migration from this document.
+A plain Python script can run the whole migration from this document.
 
 Contents:
 

docs/PLUGIN-GUIDE.md

@@ -532,9 +532,8 @@ form is `requiresAuth`; the settings subtype page is `requiresAuth + requiresAdm
 `update`, `remove`, `calibrationReport`, and a nested `types` CRUD). Do not
 reorganize the file; just add the block, mirroring `machinesApi`.
 
-**Views mirror the master templates.** The frontend has master templates the
-frontend CLAUDE.md points to (`PrintersList.vue` for lists, `PrinterDetail.vue`
-for detail pages). `measuringtools` mirrors the equivalent equipment views:
+**Views mirror the master templates.** The frontend has master templates
+(`PrintersList.vue` for lists, `PrinterDetail.vue` for detail pages). `measuringtools` mirrors the equivalent equipment views:
 
 - `views/measuringtools/MeasuringToolsList.vue` - table with search, a type filter,
   and a calibration-status filter; the status badge uses `utils/colorStyle` with

docs/ROADMAP.md

@@ -21,7 +21,7 @@ The last big milestone before 1.0 is the legacy-ASP data import plus a productio
 ### Must-have
 
 - **Asset model fully wired**. `Asset.mapx, Asset.mapy` columns, `AssetRelationship.inheritsposition`, `AssetRelationship.propagatesthroughid` columns. Models match the locked ADR-001 surface that `resolve_asset_position` already targets.
-- **Equipment data migration script** for facilities migrating from legacy ASP shopdb. One-shot script under `scripts/migration/`. See [migrating-asset-schema](../../.claude/skills/migrating-asset-schema.md) for the policy. Per ADR-001, only `category='Equipment' AND machinenumber IS NOT NULL` migrates.
+- **Equipment data migration script** for facilities migrating from legacy ASP shopdb. One-shot script under `scripts/migration/`. Per ADR-001, only `category='Equipment' AND machinenumber IS NOT NULL` migrates.
 - **Printers retirement**. Legacy `PrinterData` model, `printers_bp` legacy blueprint, and the frontend `PrinterForm.vue` references to `printer.printerdata.*` get removed in lockstep. Coordinated with the equipment migration.
 - **External plugin UI packaging**. The Vue-side hook contract ships (ADR-010: get_settings_cards / get_asset_panels / get_map_overlays / get_asset_presentation) and route gating is backend-driven (ADR-009), but plugin routes/views still live in core `frontend/src`. Let an external plugin ship its own Vue bundle so adopters can add UI without editing core.
 

docs/adr/ADR-009-frontend-plugin-gating.md

@@ -106,7 +106,7 @@ core discovers it, mirroring the backend model. Sketch:
    named extension points instead of editing core files: an `iconMap`
    registration for nav/asset icons, asset-detail panels, map-marker
    renderers, and search-result renderers (the "Frontend hook contract"
-   already listed as deferred in the project CLAUDE.md). Core exposes a
+   already listed as deferred in docs/ROADMAP.md). Core exposes a
    stable set of shared components (form controls, detail-page shells,
    table primitives) as the plugin frontend's only allowed core imports,
    the frontend analogue of the `shopdb.api` namespace.