add_concepts
Batch-create multiple ontology nodes in one call to avoid repeated round-trips after a reviewed proposal yields many accepted candidates.
Instructions
Batch-create multiple nodes in one call — same per-row shape as add_concept. Use after analyze_repo_structure or another reviewed proposal flow when the agent has K accepted candidates from the user — replaces K×add_concept round-trips. Each row is processed independently: existing-slug / invalid-kind / missing-required-fields / non-object row shape / unknown row fields surface as { slug, ok: false, error } rows whose errors include a concepts[n] row label, single unknown-field rows include receivedField plus one-row unknownFields, multi unknown-field rows report every unknown field with nearest hints and Received fields: ..., and duplicate input slugs report the later concepts[n] row plus first-seen concepts[m] with structured rowName / firstSeenAt; the rest still land. A row whose normalized title matches an earlier landed row in the same batch still lands but carries a near-duplicate warning — patch_concept the earlier node instead of forking the same concept (duplicates are the #1 growing-vault failure mode). concepts[] order in the response matches the input. Cap = 50 per call (split into multiple batches for larger sets). NO atomic rollback — if you need all-or-nothing semantics use single add_concept calls. Invalid-only batches return no row-level write metadata and no top-level postWriteMaintenance. When at least one row changes the vault, the response includes one compact postWriteMaintenance (maintenance_plan) with count-safe byPhase / bySeverity / byKind queue buckets, action score, executable proposedAction, and current-page nextExecutableAction / nextReviewAction pointers for the final graph. Rows whose title is a bare file path follow the same rule as add_concept above. Prefer one capability node covering a directory plus a short elements: list over one row per file, unless each file's role differs in a stated sentence.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| concepts | Yes | Array of concept specs (max 50). Each row uses the same shape as `add_concept` input. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| concepts | Yes | ||
| postWriteMaintenance | No | Compact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write. |