@memoarchitect/tools 0.8.8 → 0.11.0

package/packages/tools/lib/model/builder.js

@@ -37,6 +37,7 @@ import { AstUtils } from 'langium';
 import { isRequirementVerificationMember, isSatisfyRequirementUsage, isPerformActionUsage, isIncludeUseCaseUsage, isExhibitStateUsage, isFramedConcernMember, isSubjectMember, isDependency, isVariantMember, isActorMember, } from '../language/generated/ast.js';
 import { PackageRegistry } from './package-registry.js';
 import { assignSequentialShortIds, kindToPrefix } from './short-id.js';
+import { identityKey, priorShortIds } from './identity-registry.js';
 import { LANGUAGE_NATIVE_RELATIONS, REFINEMENT_METADATA, pascalToCamelCase } from './relationship-registry.js';
 import { indexKinds, kindConformsTo } from './relationship-legality.js';
 import { CONTROL_KIND_METACLASS } from './activity-notation.js';
@@ -142,12 +143,13 @@ export function buildMemoModel(documents, config, parseErrors = [], registries)
     // so emit one per nesting. A model that nests natively then looks identical
     // to one that wrote `Composes`, which is what lets R10-S7 delete the
     // relationship without the containment vanishing. Ports carry `owner` too,
-    // so this is confined to part-to-part nesting.
+    // so this covers part and item nesting, and nothing else.
+    const CONTAINING_CONSTRUCTS = new Set(['part', 'item']);
     for (const el of elements.values()) {
-        if (el.construct !== 'part' || !el.owner)
+        if (!CONTAINING_CONSTRUCTS.has(el.construct) || !el.owner)
             continue;
         const parent = elements.get(el.owner);
-        if (!parent || parent.construct !== 'part')
+        if (!parent || !CONTAINING_CONSTRUCTS.has(parent.construct))
             continue;
         relationships.push({
             id: `rel-${++relationshipCounter}`,
@@ -215,15 +217,27 @@ export function buildMemoModel(documents, config, parseErrors = [], registries)
         prefixElements.push(element);
         elementsByPrefix.set(prefix, prefixElements);
     }
+    // Identities assigned on earlier builds win. Both of these are quoted
+    // outside the model, so recomputing them from current content — which is
+    // what happened before `memo.identity.yaml` — silently repointed every
+    // external reference whenever a file moved or an element was inserted.
+    const priorIdentities = config.priorIdentities ?? {};
+    const priorShortIdsByElement = priorShortIds(priorIdentities);
     for (const [prefix, prefixElements] of elementsByPrefix) {
-        const idToShortId = assignSequentialShortIds(prefix, prefixElements.map(e => e.id));
+        const idToShortId = assignSequentialShortIds(prefix, prefixElements.map(e => e.id), priorShortIdsByElement);
         for (const el of prefixElements) {
             el.shortId = idToShortId.get(el.id);
             // `uuid` is part of the ontology's identification core, so a model
             // may author it. An authored value wins: it is the whole point of
             // writing one — the element keeps its identity across a file move
             // or an id change, which the derived hash cannot survive.
-            el.uuid = el.attributes.uuid?.trim() || stableElementUuid(el);
+            // Precedence: an authored uuid, then the one this project already
+            // assigned, then a fresh derivation. The middle term is what makes a
+            // uuid survive a file move — the derivation hashes the file path, so
+            // without it the same element gets a new identity when it moves.
+            el.uuid = el.attributes.uuid?.trim()
+                || priorIdentities[identityKey(el)]?.uuid
+                || stableElementUuid(el);
         }
     }
     // Phase 4: Validate relationship end types (warnings only).
@@ -393,7 +407,10 @@ function extractFromPackage(pkg, filePath, parentPackage, config, elements, defe
                 break;
             case 'UseCaseDeclaration': {
                 const useCase = member;
-                if (!useCase.isDefinition) {
+                if (useCase.isDefinition) {
+                    extractDefinitionElement({ name: useCase.name, specialization: useCase.specialization, body: useCase.body ?? useCase.usageBody }, 'use case', filePath, packageName, config, elements, registry, registries);
+                }
+                else {
                     extractUsage({ name: useCase.name, type: useCase.type, body: useCase.usageBody }, 'use case', filePath, packageName, config, elements, registry, registries);
                 }
                 break;
@@ -416,6 +433,9 @@ function extractFromPackage(pkg, filePath, parentPackage, config, elements, defe
             case 'ViewUsage':
                 extractUsage(member, 'view', filePath, packageName, config, elements, registry, registries);
                 break;
+            case 'ViewpointUsage':
+                extractViewpointUsage(member, filePath, packageName, config, elements, registry, registries);
+                break;
             case 'ConnectionUsage':
                 // Defer connection resolution until all elements are extracted
                 deferredConnections.push({
@@ -500,10 +520,24 @@ function extractFromPackage(pkg, filePath, parentPackage, config, elements, defe
             case 'PortDefinition':
             case 'InterfaceDefinition':
             case 'ConnectionDefinition':
+                extractDefinitionElement(member, DEFINITION_CONSTRUCTS[member.$type], filePath, packageName, config, elements, registry, registries);
                 extractDefinitionPorts(member, filePath, packageName, config, elements, registry, registries);
+                // A definition's body is composition: `part def Pump { part
+                // motor : Motor; }` is what a BDD draws and what an IBD looks
+                // inside. Nested usages become elements owned by the
+                // definition, exactly as they do under a part usage.
+                extractNestedParts(member, filePath, packageName, config, elements, registry, registries);
                 break;
-            // Other definitions (viewpoint def, view def, etc.) inside packages are
-            // ontology-level — we don't extract them as model elements in device projects
+            case 'RequirementDefinition':
+            case 'VerificationDefinition':
+            case 'StateDefinition':
+            case 'AttributeDefinition':
+            case 'EnumDefinition':
+                extractDefinitionElement(member, DEFINITION_CONSTRUCTS[member.$type], filePath, packageName, config, elements, registry, registries);
+                break;
+            // A `view def` / `viewpoint def` stays out: those are presentation
+            // apparatus, read through the viewpoint tree rather than as model
+            // content.
         }
     }
 }
@@ -625,8 +659,12 @@ function extractUsage(usage, construct, filePath, packageName, config, elements,
     // Without this, an inline-authored port silently has no element: it
     // parses, every relationship endpoint referencing it resolves to a
     // dangling id, and nothing downstream reports why.
-    if (construct === 'part') {
+    // Items nest too — a standard contains its clauses — so the nested-usage
+    // walk runs for both. Ports stay part-only: an item has no boundary.
+    if (construct === 'part' || construct === 'item') {
         extractNestedParts(usage, filePath, packageName, config, elements, registry, registries);
+    }
+    if (construct === 'part') {
         extractDefinitionPorts(usage, filePath, packageName, config, elements, registry, registries);
     }
     // A native `transition` lives inside the state machine that owns it, which
@@ -710,13 +748,30 @@ function extractActionDefinition(actionDef, filePath, packageName, config, eleme
     const attributes = extractAttributes(bodyMembers);
     const doc = extractDocComment(bodyMembers);
     const behaviorKind = actionDef.behaviorKind ?? 'action';
+    // `action def AcquireSensorData :> FunctionalAction` defines a
+    // FunctionalAction. Stamping it `ActionDefinition` named the SysML
+    // METACLASS as though it were a MEMO kind — the ontology declares no such
+    // kind, so every project action def landed in the explorer's "not in
+    // ontology" bucket, and a validator had to look it up by that literal.
+    // The metaclass is what `construct` and `isDefinition` say; the kind is
+    // what the definition specializes.
+    const superType = actionDef.specialization?.superType;
+    const resolved = superType ? resolveKindDef(superType, config, registries) : undefined;
+    const ontologyKind = resolved?.kindDef && resolved.kindDef.layer && resolved.kindDef.layer !== 'unknown'
+        ? resolved
+        : undefined;
     const element = {
         id,
         name: id,
-        kind: behaviorKind === 'operator' ? 'OperatorDefinition'
-            : behaviorKind === 'function' ? 'FunctionDefinition' : 'ActionDefinition',
+        // Only where nothing resolves does the metaclass stand in, and there it
+        // is the truthful answer: this is a SysML ActionDefinition and nothing
+        // more is known about it.
+        kind: ontologyKind?.resolvedKind
+            ?? (behaviorKind === 'operator' ? 'OperatorDefinition'
+                : behaviorKind === 'function' ? 'FunctionDefinition' : 'ActionDefinition'),
         construct: 'action',
-        layer: 'behavior',
+        isDefinition: true,
+        layer: ontologyKind?.kindDef?.layer ?? 'behavior',
         file: filePath,
         package: packageName || undefined,
         attributes: { ...attributes, behaviorKind },
@@ -802,6 +857,7 @@ function extractItemDefinition(itemDef, filePath, packageName, config, elements,
         name: id,
         kind: kindDef?.layer && kindDef.layer !== 'unknown' ? resolvedKind : 'ItemDefinition',
         construct: 'item',
+        isDefinition: true,
         layer: kindDef?.layer && kindDef.layer !== 'unknown' ? kindDef.layer : 'behavior',
         file: filePath,
         package: packageName || undefined,
@@ -826,6 +882,72 @@ function extractItemDefinition(itemDef, filePath, packageName, config, elements,
  * or a state. So the native form was the only correct one, and it was the one
  * that did not work.
  */
+/**
+ * The SysML construct each definition declares, in the spelling its usages
+ * carry — a `part def` and a `part` are the same construct, one defining and
+ * one using.
+ */
+const DEFINITION_CONSTRUCTS = {
+    PartDefinition: 'part',
+    PortDefinition: 'port',
+    InterfaceDefinition: 'interface',
+    ConnectionDefinition: 'connection',
+    RequirementDefinition: 'requirement',
+    VerificationDefinition: 'verification',
+    StateDefinition: 'state',
+    AttributeDefinition: 'attribute',
+    EnumDefinition: 'enumeration',
+};
+/**
+ * A definition the PROJECT declares, as a model element.
+ *
+ * `part def Pump :> LogicalComponent` defines a Pump. It was registered as a
+ * kind and nothing else, so no view could select it and no BDD or IBD could
+ * draw it — which is most of what a definition is for. It is an element now,
+ * and its usages read beneath it: a usage's `kind` is the definition's name,
+ * which is the link every explorer already follows.
+ *
+ * The kind it carries is the ONTOLOGY kind it specializes, so a view, a
+ * viewpoint filter and a palette that admit `LogicalComponent` admit the
+ * definition of one without being edited. `isDefinition` is what tells the two
+ * apart afterwards — a definition is a type, not an instance of one, and
+ * anything counting instances must say so.
+ *
+ * This is only ever project content: the ontology's own definitions are read
+ * by the kind registry and are never parsed into the model.
+ */
+function extractDefinitionElement(definition, construct, filePath, packageName, config, elements, registry, registries) {
+    const id = definition.name;
+    if (!id || elements.has(id))
+        return;
+    // A `library package` is how a project writes ontology-style content: its
+    // definitions are types for other models to use, not this model's content.
+    // The user's distinction exactly — model definitions become elements,
+    // library ones stay kinds, which is what they already were.
+    if (registry.isLibraryPackage(packageName))
+        return;
+    const superType = definition.specialization?.superType;
+    const { kindDef, resolvedKind } = superType
+        ? resolveKindDef(superType, config, registries)
+        : { kindDef: undefined, resolvedKind: undefined };
+    const attributes = extractAttributes(definition.body ?? []);
+    const doc = extractDocComment(definition.body ?? []);
+    elements.set(id, {
+        id,
+        name: attributes['name'] || attributes['title'] || id,
+        // A definition that specializes nothing the ontology knows is still a
+        // definition; it says so rather than borrowing a kind it has not got.
+        kind: resolvedKind ?? `${construct.charAt(0).toUpperCase()}${construct.slice(1)}Definition`,
+        construct,
+        layer: kindDef?.layer || 'unknown',
+        file: filePath,
+        package: packageName || undefined,
+        attributes,
+        doc,
+        isDefinition: true,
+    });
+    registry.registerElement(id, packageName);
+}
 function extractDefinitionPorts(def, filePath, packageName, config, elements, registry, registries) {
     const ownerId = def.name;
     const body = def.body || [];
@@ -849,8 +971,8 @@ function extractDefinitionPorts(def, filePath, packageName, config, elements, re
     }
 }
 /**
- * Walk a part usage's body to extract nested parts as owned elements, setting
- * `owner` on each child.
+ * Walk a usage's body to extract nested parts AND items as owned elements,
+ * setting `owner` on each child.
  *
  * `extractUsage` flattens the `PartMember` shapes that are view metadata — a
  * reference binding (`part viewpoint :> vp;`) and an untyped body
@@ -864,20 +986,117 @@ function extractDefinitionPorts(def, filePath, packageName, config, elements, re
 function extractNestedParts(owner, filePath, packageName, config, elements, registry, registries) {
     const ownerId = owner.name;
     for (const member of owner.body || []) {
-        if (member.$type !== 'PartMember')
-            continue;
         const pm = member;
-        // Only a TYPED nested part is containment. Untyped bodies (view
+        const isPart = pm.$type === 'PartMember';
+        // A nested ITEM is containment too — `item iec62304 { item clause4 …}`
+        // is how every standard declares its clauses. Without this branch the
+        // child parses cleanly in both parsers and never becomes an element at
+        // all: not a missing edge, a missing element. That is the
+        // BindingUsage / ExposeMember / untyped-flow shape again.
+        //
+        // A DIRECTED item is excluded: `in item payload : BubbleSignal;` is a
+        // port's payload parameter, not something the port contains. The same
+        // `direction` test already separates the two at the action-parameter
+        // and flow sites.
+        const isItem = pm.$type === 'ItemUsage' && !pm.direction;
+        if (!isPart && !isItem)
+            continue;
+        // Only a TYPED nested usage is containment. Untyped bodies (view
         // selectionQuery) and reference bindings are view metadata, flattened
         // to attributes in extractUsage — skip them here or a view's metadata
         // becomes a phantom element and its selection query is lost.
         if (!pm.type || pm.boundRef || !pm.name)
             continue;
-        extractUsage({ name: pm.name, type: pm.type, body: pm.body }, 'part', filePath, packageName, config, elements, registry, registries);
+        extractUsage({ name: pm.name, type: pm.type, body: pm.body }, isPart ? 'part' : 'item', filePath, packageName, config, elements, registry, registries);
         const childEl = elements.get(pm.name);
         if (childEl)
             childEl.owner = ownerId;
     }
+    extractNestedPackages(owner, filePath, packageName, config, elements, registry, registries);
+}
+/**
+ * A `package` nested inside a usage body — `part scrHome : UIElement { package
+ * grpHeader { part btnBack : UIElement; } }`.
+ *
+ * A package GROUPS; it does not decompose. So the group becomes an element (the
+ * explorer needs a node to render, and the user asked to create these to
+ * organise a screen or a leaf of the model), but the things inside it stay
+ * contained by the OWNER — putting them under the package would assert a part
+ * decomposition the author did not write, and would make the containment
+ * family rules see a package "containing" software.
+ *
+ * Without this the package and everything in it parses in both parsers and
+ * never becomes an element: the BindingUsage / ExposeMember / nested-item shape
+ * for the fourth time.
+ */
+function extractNestedPackages(owner, filePath, packageName, config, elements, registry, registries) {
+    for (const member of owner.body || []) {
+        const pm = member;
+        if (pm.$type !== 'PackageDeclaration' || !pm.name)
+            continue;
+        elements.set(pm.name, {
+            id: pm.name,
+            name: pm.name,
+            kind: ELEMENT_PACKAGE_KIND,
+            construct: 'package',
+            layer: elements.get(owner.name)?.layer ?? 'unknown',
+            file: filePath,
+            package: packageName,
+            attributes: {},
+            owner: owner.name,
+        });
+        for (const grouped of pm.members ?? []) {
+            const gm = grouped;
+            // `part btnBack : UIElement;` parses as a PartMember and
+            // `part btnBack : UIElement { … }` as a PartUsage — the same
+            // declaration with and without a body. Accepting only the first
+            // dropped every grouped element that declares anything, which is
+            // most of them.
+            const isPart = gm.$type === 'PartMember' || gm.$type === 'PartUsage';
+            const isItem = gm.$type === 'ItemUsage' && !gm.direction;
+            if (!isPart && !isItem)
+                continue;
+            if (!gm.type || gm.boundRef || !gm.name)
+                continue;
+            extractUsage({ name: gm.name, type: gm.type, body: gm.body }, isPart ? 'part' : 'item', filePath, packageName, config, elements, registry, registries);
+            const childEl = elements.get(gm.name);
+            if (childEl) {
+                // Contained by the OWNER; the package only labels the grouping.
+                childEl.owner = owner.name;
+                childEl.attributes['elementPackage'] = pm.name;
+            }
+        }
+    }
+}
+/** The kind a nested grouping package becomes, distinct from a namespace package. */
+export const ELEMENT_PACKAGE_KIND = 'ElementPackage';
+/**
+ * A `viewpoint` usage, and any viewpoint declared inside it.
+ *
+ * A viewpoint nests for system-of-systems modelling: the viewpoint that frames
+ * the whole system of systems declares one viewpoint per constituent system,
+ * which is how ISO 42010 composes a description of a description. Native SysML
+ * already permits it (`ViewpointUsage` is a `UsageBodyMember`) and the grammar
+ * already parsed it — nothing extracted it, so a nested viewpoint became no
+ * element at all and every consumer saw one flat list.
+ *
+ * The nested viewpoint carries its parent in `owner`, the same way a nested
+ * part does. Unlike a part, no `composes` edge is synthesized: a viewpoint is
+ * not a `part` construct, and framing is not containment of hardware.
+ */
+function extractViewpointUsage(usage, filePath, packageName, config, elements, registry, registries, ownerId) {
+    if (!usage.name)
+        return;
+    extractUsage({ name: usage.name, type: usage.type, body: usage.body }, 'viewpoint', filePath, packageName, config, elements, registry, registries);
+    const element = elements.get(usage.name);
+    if (element && ownerId)
+        element.owner = ownerId;
+    for (const member of usage.body || []) {
+        const nested = member;
+        if (nested.$type !== 'ViewpointUsage')
+            continue;
+        extractViewpointUsage(nested, filePath, packageName, config, elements, registry, registries, usage.name);
+    }
 }
 /**
  * Extract an ActionUsage, including nested actions, flows, and successions.
@@ -1001,14 +1220,18 @@ function resolveConnection(conn, filePath, packageName, config, elements, relati
         return;
     // A named connection usage carries its own stable ID; anonymous ones fall
     // back to a positional counter that shifts whenever the file changes.
-    const attributes = { ...extractAttributes(conn.body), ...extractRelationshipMetadata(conn.body) };
+    // `extractAttributes` lifts metadata applications itself now, so the
+    // connection path no longer needs its own second pass.
+    const attributes = extractAttributes(conn.body);
     const rel = {
         id: conn.name || `rel-${++relationshipCounter}`,
         type: normalizedType,
         sourceId,
-        sourceEnd: conn.source.endName,
+        // `connect a to b` omits the end names; the ends are then the inherited
+        // `source`/`target` participants. csv-io already defaults the same way.
+        sourceEnd: conn.source.endName ?? 'source',
         targetId,
-        targetEnd: conn.target.endName,
+        targetEnd: conn.target.endName ?? 'target',
         file: filePath,
         sourceRange: conn.$cstNode
             ? { offset: conn.$cstNode.offset, length: conn.$cstNode.length }
@@ -1046,7 +1269,15 @@ function resolveConnection(conn, filePath, packageName, config, elements, relati
  * mismatch on whichever edge happened to carry a different item from its
  * parent's.
  *
- * Walk the path through `owner` and take the deepest real element.
+ * Walk the path through the parent link and take the deepest real element.
+ *
+ * A nested part or port records its parent in `owner`; a nested ACTION records
+ * it in `parentAction`, because the two are set by separate extraction paths.
+ * Reading only `owner` broke the walk at the first hop of every function path:
+ * `flow from fnDeliverTherapy.fnMeterFluid.fnMeasureDelivered to …` became a
+ * self-loop on `fnDeliverTherapy`, which is a plausible-looking edge pointing
+ * at the wrong function — the exact failure the comment above describes, one
+ * field away from where it was fixed for ports.
  */
 function resolveEndpoint(ref, elements) {
     const parts = ref.split('.');
@@ -1054,7 +1285,7 @@ function resolveEndpoint(ref, elements) {
     let i = 1;
     while (i < parts.length) {
         const child = elements.get(parts[i]);
-        if (!child || child.owner !== id)
+        if (!child || (child.owner !== id && child.parentAction !== id))
             break;
         id = parts[i];
         i++;
@@ -1125,7 +1356,13 @@ function resolveFlowConnection(flow, filePath, packageName, parentActionId, rela
 }
 /**
  * Resolve a succession usage into pairs of MemoRelationships.
- * "first start then A then B then done" → (start→A), (A→B), (B→done)
+ * "first A then B" → (A→B).
+ *
+ * The grammar admits exactly one `then` per statement, matching KerML
+ * `SuccessionDeclaration` (:845), so `steps` is always a pair here. The loop
+ * below is still written over the whole array: it costs nothing, and it keeps
+ * this function correct for the chained input the deferred-succession path at
+ * the call site synthesizes.
  */
 function resolveSuccession(succession, filePath, packageName, parentActionId, relationships, allElementIds) {
     const steps = succession.steps || [];
@@ -1408,8 +1645,9 @@ function resolveActorParticipation(actor, filePath, relationships, registry, all
  * name/doc, not in a relationship type.
  */
 function resolveDependency(dependency, filePath, relationships, registry, allElementIds) {
-    const isRefinement = (dependency.prefixMetadata ?? [])
-        .some(annotation => annotation.type?.split('::').pop() === REFINEMENT_METADATA);
+    const prefixes = (dependency.prefixMetadata ?? [])
+        .map(annotation => annotation.type?.split('::').pop());
+    const isRefinement = prefixes.includes(REFINEMENT_METADATA);
     const { packageName } = nativeUsageContext(dependency);
     for (const client of dependency.clients ?? []) {
         const sourceId = resolveEndpointId(client, packageName, registry, allElementIds);
@@ -1547,33 +1785,56 @@ function extractAttributes(body) {
             }
         }
     }
+    // Metadata applications last, so an annotation overrides a directly declared
+    // attribute of the same name. That order is what R10-S5 established for
+    // connections and it is preserved here rather than re-litigated: while the
+    // identification core is migrating off the base defs, an element may carry
+    // both spellings, and the annotation is the newer statement of intent.
+    Object.assign(attrs, extractMetadataApplications(body));
     return attrs;
 }
 /**
- * Read the standard `Rationale`/`StatusInfo` metadata (ModelingMetadata.sysml)
- * off a connection usage's body into the same flat attribute keys the deleted
- * `MemoRelationship.rationale`/`.status` used to occupy (R10-S5, 2026-08-13).
+ * Standard metadata whose field name differs from the flat key MEMO reads.
+ * Everything else lifts under its own field name, which is what makes one
+ * `metadata def` usable as a carrier for any element.
+ */
+const METADATA_KEY_ALIASES = {
+    Rationale: { text: 'rationale' },
+};
+/**
+ * Lift every `@Foo { ... }` metadata application in a body into the flat
+ * attribute map, under each field's own name.
+ *
+ * `extractAttributes`'s member walk covers `AttributeMember`/`RefMember`/
+ * `MetadataFeatureMember`; a `MetadataApplication` is a different node type and
+ * is invisible to it, so without this an annotation parses cleanly in both
+ * parsers and then silently vanishes from the model — the BindingUsage /
+ * ExposeMember / untyped-flow shape this codebase has already hit three times.
  *
- * `extractAttributes` only walks `AttributeMember`/`RefMember`/
- * `MetadataFeatureMember`; a `MetadataApplication` in a usage body (the `@Foo
- * {...}` form) is invisible to it, so without this a `@Rationale`/`@StatusInfo`
- * annotation would parse and silently vanish from the model — the same
- * BindingUsage/ExposeMember shape this epic exists to stop repeating.
+ * This started (R10-S5, 2026-08-13) as a connection-only reader hardcoded to
+ * `Rationale.text` and `StatusInfo.status`, because those were the two base-type
+ * attributes being deleted at the time. It is general now for one reason: a
+ * `metadata def` is the only carrier in SysML v2 that attaches to ANY metaclass,
+ * so it is how MEMO can hold common fields (`id`, `uuid`, `sourceReference`, …)
+ * without re-declaring them per metaclass. A carrier the builder cannot read is
+ * not a carrier, so the reader has to be as general as the mechanism.
+ *
+ * Fields lift under their own names; `METADATA_KEY_ALIASES` covers the standard
+ * definitions whose field name differs from the key MEMO reads.
  */
-function extractRelationshipMetadata(body) {
+function extractMetadataApplications(body) {
     if (!body)
         return {};
     const attrs = {};
     for (const member of body) {
         if (member.$type !== 'MetadataApplication')
             continue;
-        const metadataType = member.type?.split('::').pop();
-        const fields = extractAttributes(member.body);
-        if (metadataType === 'Rationale' && fields.text) {
-            attrs.rationale = fields.text;
-        }
-        else if (metadataType === 'StatusInfo' && fields.status) {
-            attrs.status = fields.status;
+        const metadataType = member.type?.split('::').pop() ?? '';
+        const aliases = METADATA_KEY_ALIASES[metadataType] ?? {};
+        for (const [field, value] of Object.entries(extractAttributes(member.body))) {
+            if (value === '')
+                continue;
+            attrs[aliases[field] ?? field] = value;
         }
     }
     return attrs;