Vessel onboarding (natural flow)

ADMINISTRATOR The authoritative onboarding sequence is defined in the Tracked matters — vessel onboarding natural-flow spec. Follow it in order. Each step has a green check before you can advance.

Sequence

1. Add vessel — Admin → Fleet → Vessels → New vessel. Just name and imo to start (no M/V prefix; store EGOR LETOV, not M/V EGOR LETOV).
2. Particulars upload — Class & Flag Documents wizard, slot particulars. Triggers general_particulars extractor → vessel_particulars row + provenance entries. IMO + DWT (Summer Salt Water) become authoritative on approval and propagate to vessels.
3. GA Plan upload — wizard slot ga_plan. Triggers general_arrangement extractor → vessel_equipment_inventory + vessel_tanks (nested in vessel_particulars.json_blob).
4. Sister-vessel detection — automatic on dimensions + flag + class. If a sister is found, particulars and equipment can be inherited (operator confirms).
5. CL Skeleton wizard (12 steps) — Admin → Components → CL Builds → New build. Blocked unless the 6 mandatory blockers are present (Particulars, Capacity Plan, GA Plan, Form E/SER, GMDSS, ECDIS). Vessel CL + Loading Manual are helpful, not blocking.
6. Helper-doc agent (B1 milestone — agent-only, not in the UI) — Markdown layer that explains relationships in narrative form to the population agent.
7. Canonical import — POST /api/vessels/:id/components/import (207 Multi-Status, with structured rejected[] reasons).
8. Dashboard live — operator can now view dashboards and drafts.

Delete-ship preserves RAG

Deleting a vessel removes the vessels row + assignments, but preserves rag_chunks and cl_knowledge_base entries by design. So onboarding the same IMO again warm-starts retrieval.

Master List is unique

Every component in every vessel CL must have its code come from the active ucs_master_list. Inventing codes is forbidden. The CL Skeleton runner refuses to emit rows for codes not in the active Master.