@memoarchitect/tools 0.7.2 → 0.8.8

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (167) hide show
  1. package/README.md +1 -1
  2. package/corpus/README.md +63 -0
  3. package/corpus/sysml-v2-release/bnf/SysML-graphical-bnf.kgbnf +2264 -0
  4. package/package.json +4 -3
  5. package/packages/tools/lib/analysis/dsm.d.ts +1 -1
  6. package/packages/tools/lib/analysis/dsm.d.ts.map +1 -1
  7. package/packages/tools/lib/analysis/dsm.js +1 -1
  8. package/packages/tools/lib/analysis/dsm.js.map +1 -1
  9. package/packages/tools/lib/bin/memo.js +25 -0
  10. package/packages/tools/lib/bin/memo.js.map +1 -1
  11. package/packages/tools/lib/browser/index.d.ts +2 -0
  12. package/packages/tools/lib/browser/index.d.ts.map +1 -1
  13. package/packages/tools/lib/browser/index.js +1 -0
  14. package/packages/tools/lib/browser/index.js.map +1 -1
  15. package/packages/tools/lib/commands/dev.d.ts.map +1 -1
  16. package/packages/tools/lib/commands/dev.js +37 -15
  17. package/packages/tools/lib/commands/dev.js.map +1 -1
  18. package/packages/tools/lib/commands/dhf-lint.d.ts +10 -0
  19. package/packages/tools/lib/commands/dhf-lint.d.ts.map +1 -0
  20. package/packages/tools/lib/commands/dhf-lint.js +72 -0
  21. package/packages/tools/lib/commands/dhf-lint.js.map +1 -0
  22. package/packages/tools/lib/commands/dhf.d.ts.map +1 -1
  23. package/packages/tools/lib/commands/dhf.js +7 -1
  24. package/packages/tools/lib/commands/dhf.js.map +1 -1
  25. package/packages/tools/lib/commands/standards.d.ts +28 -0
  26. package/packages/tools/lib/commands/standards.d.ts.map +1 -0
  27. package/packages/tools/lib/commands/standards.js +203 -0
  28. package/packages/tools/lib/commands/standards.js.map +1 -0
  29. package/packages/tools/lib/commands/validate.d.ts.map +1 -1
  30. package/packages/tools/lib/commands/validate.js +13 -2
  31. package/packages/tools/lib/commands/validate.js.map +1 -1
  32. package/packages/tools/lib/dhf/document-compiler.d.ts.map +1 -1
  33. package/packages/tools/lib/dhf/document-compiler.js +13 -8
  34. package/packages/tools/lib/dhf/document-compiler.js.map +1 -1
  35. package/packages/tools/lib/dhf/document-registry.d.ts +16 -2
  36. package/packages/tools/lib/dhf/document-registry.d.ts.map +1 -1
  37. package/packages/tools/lib/dhf/document-registry.js +74 -23
  38. package/packages/tools/lib/dhf/document-registry.js.map +1 -1
  39. package/packages/tools/lib/dhf/index.d.ts +3 -0
  40. package/packages/tools/lib/dhf/index.d.ts.map +1 -1
  41. package/packages/tools/lib/dhf/index.js +4 -0
  42. package/packages/tools/lib/dhf/index.js.map +1 -1
  43. package/packages/tools/lib/dhf/query-engine.d.ts +12 -1
  44. package/packages/tools/lib/dhf/query-engine.d.ts.map +1 -1
  45. package/packages/tools/lib/dhf/query-engine.js +2 -1
  46. package/packages/tools/lib/dhf/query-engine.js.map +1 -1
  47. package/packages/tools/lib/dhf/query-executor.d.ts +72 -5
  48. package/packages/tools/lib/dhf/query-executor.d.ts.map +1 -1
  49. package/packages/tools/lib/dhf/query-executor.js +471 -81
  50. package/packages/tools/lib/dhf/query-executor.js.map +1 -1
  51. package/packages/tools/lib/dhf/script-runner.js +6 -6
  52. package/packages/tools/lib/dhf/script-runner.js.map +1 -1
  53. package/packages/tools/lib/dhf/standards-block.d.ts +40 -0
  54. package/packages/tools/lib/dhf/standards-block.d.ts.map +1 -0
  55. package/packages/tools/lib/dhf/standards-block.js +223 -0
  56. package/packages/tools/lib/dhf/standards-block.js.map +1 -0
  57. package/packages/tools/lib/dhf/standards-library.d.ts +123 -0
  58. package/packages/tools/lib/dhf/standards-library.d.ts.map +1 -0
  59. package/packages/tools/lib/dhf/standards-library.js +295 -0
  60. package/packages/tools/lib/dhf/standards-library.js.map +1 -0
  61. package/packages/tools/lib/dhf/standards-report.d.ts +189 -0
  62. package/packages/tools/lib/dhf/standards-report.d.ts.map +1 -0
  63. package/packages/tools/lib/dhf/standards-report.js +384 -0
  64. package/packages/tools/lib/dhf/standards-report.js.map +1 -0
  65. package/packages/tools/lib/dhf/template-lint.d.ts +42 -0
  66. package/packages/tools/lib/dhf/template-lint.d.ts.map +1 -0
  67. package/packages/tools/lib/dhf/template-lint.js +421 -0
  68. package/packages/tools/lib/dhf/template-lint.js.map +1 -0
  69. package/packages/tools/lib/dhf/template-resolver.d.ts.map +1 -1
  70. package/packages/tools/lib/dhf/template-resolver.js +17 -5
  71. package/packages/tools/lib/dhf/template-resolver.js.map +1 -1
  72. package/packages/tools/lib/importer/cameo-importer.js +2 -2
  73. package/packages/tools/lib/importer/cameo-importer.js.map +1 -1
  74. package/packages/tools/lib/importer/ea-importer.d.ts.map +1 -1
  75. package/packages/tools/lib/importer/ea-importer.js +4 -3
  76. package/packages/tools/lib/importer/ea-importer.js.map +1 -1
  77. package/packages/tools/lib/importer/owl-importer.d.ts.map +1 -1
  78. package/packages/tools/lib/importer/owl-importer.js +2 -3
  79. package/packages/tools/lib/importer/owl-importer.js.map +1 -1
  80. package/packages/tools/lib/language/generated/ast.d.ts +1172 -54
  81. package/packages/tools/lib/language/generated/ast.d.ts.map +1 -1
  82. package/packages/tools/lib/language/generated/ast.js +967 -39
  83. package/packages/tools/lib/language/generated/ast.js.map +1 -1
  84. package/packages/tools/lib/language/generated/grammar.d.ts.map +1 -1
  85. package/packages/tools/lib/language/generated/grammar.js +3694 -425
  86. package/packages/tools/lib/language/generated/grammar.js.map +1 -1
  87. package/packages/tools/lib/model/builder.d.ts.map +1 -1
  88. package/packages/tools/lib/model/builder.js +730 -48
  89. package/packages/tools/lib/model/builder.js.map +1 -1
  90. package/packages/tools/lib/model/kind-registry.d.ts +20 -0
  91. package/packages/tools/lib/model/kind-registry.d.ts.map +1 -1
  92. package/packages/tools/lib/model/kind-registry.js +38 -0
  93. package/packages/tools/lib/model/kind-registry.js.map +1 -1
  94. package/packages/tools/lib/model/manifest.d.ts +8 -0
  95. package/packages/tools/lib/model/manifest.d.ts.map +1 -1
  96. package/packages/tools/lib/model/manifest.js +3 -0
  97. package/packages/tools/lib/model/manifest.js.map +1 -1
  98. package/packages/tools/lib/model/naming.d.ts +57 -0
  99. package/packages/tools/lib/model/naming.d.ts.map +1 -0
  100. package/packages/tools/lib/model/naming.js +69 -0
  101. package/packages/tools/lib/model/naming.js.map +1 -0
  102. package/packages/tools/lib/model/native-project.d.ts +10 -7
  103. package/packages/tools/lib/model/native-project.d.ts.map +1 -1
  104. package/packages/tools/lib/model/native-project.js +76 -21
  105. package/packages/tools/lib/model/native-project.js.map +1 -1
  106. package/packages/tools/lib/model/ontology-loader.d.ts.map +1 -1
  107. package/packages/tools/lib/model/ontology-loader.js +3 -0
  108. package/packages/tools/lib/model/ontology-loader.js.map +1 -1
  109. package/packages/tools/lib/model/package-manifest.d.ts +4 -0
  110. package/packages/tools/lib/model/package-manifest.d.ts.map +1 -1
  111. package/packages/tools/lib/model/package-manifest.js +2 -0
  112. package/packages/tools/lib/model/package-manifest.js.map +1 -1
  113. package/packages/tools/lib/model/relationship-legality.d.ts +17 -0
  114. package/packages/tools/lib/model/relationship-legality.d.ts.map +1 -1
  115. package/packages/tools/lib/model/relationship-legality.js.map +1 -1
  116. package/packages/tools/lib/model/relationship-registry.d.ts +77 -0
  117. package/packages/tools/lib/model/relationship-registry.d.ts.map +1 -1
  118. package/packages/tools/lib/model/relationship-registry.js +217 -2
  119. package/packages/tools/lib/model/relationship-registry.js.map +1 -1
  120. package/packages/tools/lib/model/semantic.d.ts +48 -0
  121. package/packages/tools/lib/model/semantic.d.ts.map +1 -1
  122. package/packages/tools/lib/model/semantic.js +3 -0
  123. package/packages/tools/lib/model/semantic.js.map +1 -1
  124. package/packages/tools/lib/model/settings-boundary.js +1 -1
  125. package/packages/tools/lib/model/settings-boundary.js.map +1 -1
  126. package/packages/tools/lib/model/short-id.d.ts.map +1 -1
  127. package/packages/tools/lib/model/short-id.js +1 -3
  128. package/packages/tools/lib/model/short-id.js.map +1 -1
  129. package/packages/tools/lib/model/view-deriver.d.ts +10 -1
  130. package/packages/tools/lib/model/view-deriver.d.ts.map +1 -1
  131. package/packages/tools/lib/model/view-deriver.js +104 -5
  132. package/packages/tools/lib/model/view-deriver.js.map +1 -1
  133. package/packages/tools/lib/protocol/messages.d.ts +85 -3
  134. package/packages/tools/lib/protocol/messages.d.ts.map +1 -1
  135. package/packages/tools/lib/server/dev-server.d.ts.map +1 -1
  136. package/packages/tools/lib/server/dev-server.js +161 -5
  137. package/packages/tools/lib/server/dev-server.js.map +1 -1
  138. package/packages/tools/lib/server/package-source.d.ts +26 -0
  139. package/packages/tools/lib/server/package-source.d.ts.map +1 -0
  140. package/packages/tools/lib/server/package-source.js +81 -0
  141. package/packages/tools/lib/server/package-source.js.map +1 -0
  142. package/packages/tools/lib/server/package-writer.d.ts +94 -0
  143. package/packages/tools/lib/server/package-writer.d.ts.map +1 -0
  144. package/packages/tools/lib/server/package-writer.js +317 -0
  145. package/packages/tools/lib/server/package-writer.js.map +1 -0
  146. package/packages/tools/lib/server/persistor.d.ts +20 -0
  147. package/packages/tools/lib/server/persistor.d.ts.map +1 -1
  148. package/packages/tools/lib/server/persistor.js +29 -8
  149. package/packages/tools/lib/server/persistor.js.map +1 -1
  150. package/packages/tools/lib/server/relationship-writer.d.ts +13 -1
  151. package/packages/tools/lib/server/relationship-writer.d.ts.map +1 -1
  152. package/packages/tools/lib/server/relationship-writer.js +59 -0
  153. package/packages/tools/lib/server/relationship-writer.js.map +1 -1
  154. package/packages/tools/lib/server/sysml-notation.d.ts +1 -1
  155. package/packages/tools/lib/server/sysml-notation.d.ts.map +1 -1
  156. package/packages/tools/lib/server/sysml-notation.js +17 -0
  157. package/packages/tools/lib/server/sysml-notation.js.map +1 -1
  158. package/packages/tools/lib/server/view-layout-store.d.ts.map +1 -1
  159. package/packages/tools/lib/server/view-layout-store.js +1 -0
  160. package/packages/tools/lib/server/view-layout-store.js.map +1 -1
  161. package/packages/tools/lib/validator/behavior-validator.d.ts +1 -1
  162. package/packages/tools/lib/validator/behavior-validator.js +1 -1
  163. package/packages/tools/lib/validator/constraint-eval.d.ts +16 -0
  164. package/packages/tools/lib/validator/constraint-eval.d.ts.map +1 -1
  165. package/packages/tools/lib/validator/constraint-eval.js +102 -0
  166. package/packages/tools/lib/validator/constraint-eval.js.map +1 -1
  167. package/packages/tools/src/grammar/memo-sysml.langium +425 -26
@@ -40,6 +40,7 @@ NamespaceMember:
40
40
  | AliasDeclaration
41
41
  | DefinitionMember
42
42
  | UseCaseDeclaration
43
+ | Dependency
43
44
  | DocComment;
44
45
 
45
46
  // ─── Package ─────────────────────────────────────────────────────────────────
@@ -72,11 +73,27 @@ PackageMember:
72
73
  | UseCaseDeclaration
73
74
  | FlowConnectionUsage
74
75
  | SuccessionUsage
76
+ | AbstractConnectionUsage
75
77
  | ConnectionUsage
76
- | AllocateUsage
78
+ | SatisfyRequirementUsage
79
+ // Contributes AllocateUsage along with the thirteen other native
80
+ // mechanisms. MEMO declares its actors, stakeholders and concerns as
81
+ // PACKAGE members (`part usrClinician : User;`), so their native spellings
82
+ // have to be legal in the same place or the migration could not be a
83
+ // spelling change.
84
+ | ArcadiaMember
85
+ | Dependency
77
86
  | MetadataApplication
87
+ | BindingUsage
78
88
  | DocComment;
79
89
 
90
+ // `bind a = b;` — the native spelling of port delegation, where an enclosing
91
+ // port and a nested part's port are the same feature. MEMO wrote these as
92
+ // flows, which SysIDE rejects: a flow's source must be an output, and a
93
+ // delegation runs `in` to `in`.
94
+ BindingUsage:
95
+ 'bind' source=ReferenceName '=' target=ReferenceName ';';
96
+
80
97
  // Namespace indirection used by the canonical memo::* facade. Each source file
81
98
  // owns a unique package for reliable SysIDE indexing; aliases reconstruct the
82
99
  // user-facing hierarchy without reopening packages across documents.
@@ -110,6 +127,8 @@ DefinitionMember:
110
127
  | PortDefinition
111
128
  | InterfaceDefinition
112
129
  | ConnectionDefinition
130
+ | AllocationDefinition
131
+ | ConcernDefinition
113
132
  | AttributeDefinition
114
133
  | ConstraintDefinition
115
134
  | EnumDefinition
@@ -119,17 +138,49 @@ DefinitionMember:
119
138
 
120
139
  // SysML v2 semantic-metadata definition — the standard, portable mechanism for
121
140
  // extending the ontology with domain semantics. Applied to elements via `@Name`.
141
+ // The optional `<shortName>` is SysML v2's Identification short name, and for a
142
+ // SemanticMetadata it is the KEYWORD the metadata introduces — `<derive>` in the
143
+ // OMG's own `metadata def <derive> DerivedRequirementMetadata :> SemanticMetadata`
144
+ // (Domain Libraries/Requirement Derivation/RequirementDerivation.sysml). Without
145
+ // it a metadata def cannot say which word it defines, which is most of the point.
146
+ //
147
+ // The short name is lexed as ONE token rather than as `'<' ID '>'`, because the
148
+ // word it introduces is almost always already a keyword — `<allocate>` and
149
+ // `<derive>` both fail an ID match. A keyword is exactly what a metadata def
150
+ // exists to introduce, so the production must not be restricted to non-keywords.
122
151
  MetadataDefinition:
123
- 'metadata' 'def' name=ID specialization=Specialization?
152
+ 'metadata' 'def' shortName=SHORT_NAME? name=ID specialization=Specialization?
124
153
  ('{' body+=DefinitionBodyMember* '}' | ';');
125
154
 
126
155
  // Metadata application: `@AnnotationType;` or `@AnnotationType { redefinitions }`
127
156
  // applies a metadata def to the enclosing element (standard SysML v2 `@` annotation).
128
157
  MetadataApplication:
129
- '@' type=QualifiedName ('{' body+=UsageBodyMember* '}' | ';');
130
-
158
+ '@' type=QualifiedName ('{' body+=MetadataBodyMember* '}' | ';');
159
+
160
+ // Inside a metadata body the `attribute` keyword is NOT accepted — SysIDE's
161
+ // own expected-token list at that position offers `:>>` and `redefines` but
162
+ // not `attribute`, because the members of a metadata usage are already
163
+ // features of its definition. So the bare redefinition is the conforming
164
+ // spelling here and `attribute :>> x = …` is the error, the reverse of every
165
+ // other body in this grammar. Measured against `syside check`, which is the
166
+ // compiler of record.
167
+ MetadataBodyMember:
168
+ MetadataFeatureMember | UsageBodyMember;
169
+
170
+ MetadataFeatureMember:
171
+ redefines?=('redefines' | ':>>') name=MemberName '=' value=AttributeValue ';';
172
+
173
+ // `isVariation` is the second half of the normative `BasicDefinitionPrefix`
174
+ // (`isAbstract ?= 'abstract' | isVariation ?= 'variation'`,
175
+ // SysML-textual-bnf.kebnf:224). A variation definition is a CHOICE POINT: its
176
+ // `variant` members are the alternatives, exactly one of which a configuration
177
+ // picks. That is the construct ARCADIA configurations and situations need, and
178
+ // the one AADL mode-conditioned configuration needs (plan §C4); MEMO could not
179
+ // express either. It is declared on part / attribute / item, which is where a
180
+ // choice point can occur in MEMO's content — not on every definition, because a
181
+ // production nobody can reach is not coverage.
131
182
  PartDefinition:
132
- isAbstract?='abstract'? 'part' 'def' name=ID specialization=Specialization? (',' additionalSpecializations+=QualifiedName)*
183
+ isAbstract?='abstract'? isVariation?='variation'? 'part' 'def' name=ID specialization=Specialization? (',' additionalSpecializations+=QualifiedName)*
133
184
  ('{' body+=DefinitionBodyMember* '}' | ';');
134
185
 
135
186
  RequirementDefinition:
@@ -153,7 +204,7 @@ ActionDefinition:
153
204
  ('{' body+=ActionDefBodyMember* '}' | ';');
154
205
 
155
206
  ItemDefinition:
156
- isAbstract?='abstract'? 'item' 'def' name=ID specialization=Specialization? (',' additionalSpecializations+=QualifiedName)*
207
+ isAbstract?='abstract'? isVariation?='variation'? 'item' 'def' name=ID specialization=Specialization? (',' additionalSpecializations+=QualifiedName)*
157
208
  ('{' body+=DefinitionBodyMember* '}' | ';');
158
209
 
159
210
  PortDefinition:
@@ -170,17 +221,43 @@ ConnectionDefinition:
170
221
  isAbstract?='abstract'? 'connection' 'def' name=ID specialization=Specialization? (',' additionalSpecializations+=QualifiedName)*
171
222
  ('{' body+=ConnectionBodyMember* '}' | ';');
172
223
 
224
+ // SysML v2 allocation definition (`AllocationDefinition = OccurrenceDefinitionPrefix
225
+ // 'allocation' 'def' Definition`, SysML-textual-bnf.kebnf:792). An allocation IS a
226
+ // connection — `Allocations::Allocation :> BinaryConnection` — so it takes the same
227
+ // body as a connection def, and `allocation def X :> Allocations::Allocation` is
228
+ // what lets MEMO's AllocatedTo / DeploysTo / BuildsInto root on the standard's
229
+ // allocation base instead of standing beside it (plan B2).
230
+ AllocationDefinition:
231
+ isAbstract?='abstract'? 'allocation' 'def' name=ID specialization=Specialization? (',' additionalSpecializations+=QualifiedName)*
232
+ ('{' body+=ConnectionBodyMember* '}' | ';');
233
+
234
+ // SysML v2 concern definition (`ConcernDefinition = OccurrenceDefinitionPrefix
235
+ // 'concern' 'def' DefinitionDeclaration RequirementBody`, :1493). ISO 42010's
236
+ // concern, which MEMO spells `part def Concern`. Its body is a requirement body,
237
+ // so it may carry `subject`, `stakeholder`, and `frame` members. Those reach it
238
+ // through DefinitionBodyMember rather than through a concern-only body rule —
239
+ // the same choice the grammar already makes for `verify`, and for the same
240
+ // reason: SysIDE is the compiler of record for where a member is legal, and a
241
+ // per-construct body rule here would only duplicate that judgement less well.
242
+ ConcernDefinition:
243
+ isAbstract?='abstract'? 'concern' 'def' name=ID specialization=Specialization? (',' additionalSpecializations+=QualifiedName)*
244
+ ('{' body+=DefinitionBodyMember* '}' | ';');
245
+
173
246
  AttributeDefinition:
174
- isAbstract?='abstract'? 'attribute' 'def' name=ID specialization=Specialization? (',' additionalSpecializations+=QualifiedName)*
247
+ isAbstract?='abstract'? isVariation?='variation'? 'attribute' 'def' name=ID specialization=Specialization? (',' additionalSpecializations+=QualifiedName)*
175
248
  ('{' body+=DefinitionBodyMember* '}' | ';');
176
249
 
177
250
  ConstraintDefinition:
178
251
  isAbstract?='abstract'? 'constraint' 'def' name=ID specialization=Specialization? (',' additionalSpecializations+=QualifiedName)*
179
252
  ('{' body+=DefinitionBodyMember* '}' | ';');
180
253
 
254
+ // An enum body may carry doc comments between its literals. SysIDE accepts
255
+ // them and MEMO did not, so a documented enumeration — which is the only place
256
+ // the meaning of a literal can be written down — failed to parse. `literals`
257
+ // keeps its name and its contents so every existing consumer is unaffected.
181
258
  EnumDefinition:
182
259
  'enum' 'def' name=ID '{'
183
- literals+=EnumLiteral*
260
+ (literals+=EnumLiteral | docs+=DocComment)*
184
261
  '}';
185
262
 
186
263
  ViewpointDefinition:
@@ -194,10 +271,15 @@ ViewDefinition:
194
271
  // ─── Connection definition body ─────────────────────────────────────────────
195
272
 
196
273
  ConnectionBodyMember:
197
- EndDeclaration | DefinitionBodyMember;
274
+ EndDeclaration | FlowConnectionUsage | DefinitionBodyMember;
198
275
 
276
+ // An end may redefine the inherited end of its supertype — in MEMO every
277
+ // relation binds its two ends to Connections::BinaryConnection::source and
278
+ // ::target, so the ends of a MEMO relation are readable as ordinary SysML
279
+ // connection ends by any conforming tool.
199
280
  EndDeclaration:
200
- 'end' name=FeatureName (':' isConjugated?='~'? type=QualifiedName)? multiplicity=Multiplicity? ';';
281
+ 'end' name=FeatureName (':' isConjugated?='~'? type=QualifiedName)? multiplicity=Multiplicity?
282
+ (redefines?=(':>>' | 'redefines') redefinedEnd=QualifiedName)? ';';
201
283
 
202
284
  Multiplicity:
203
285
  '[' lower=INT '..' (upper=INT | unbounded?='*') ']'
@@ -214,12 +296,14 @@ EnumLiteralName returns string:
214
296
  | 'in' | 'out' | 'inout' | 'part' | 'requirement' | 'action' | 'item' | 'port'
215
297
  | 'interface' | 'connection' | 'attribute' | 'constraint' | 'enum' | 'view' | 'viewpoint'
216
298
  | 'ref' | 'import' | 'package' | 'flow' | 'first' | 'allocate' | 'library' | 'private' | 'public' | 'state' | 'verification'
299
+ | 'satisfy' | 'verify'
217
300
  | 'use' | 'fork' | 'join';
218
301
 
219
302
  // ─── Usages (instances) ─────────────────────────────────────────────────────
220
303
 
221
304
  UsageMember:
222
305
  PartUsage
306
+ | MessageUsage
223
307
  | RequirementUsage
224
308
  | VerificationUsage
225
309
  | StateUsage
@@ -229,7 +313,11 @@ UsageMember:
229
313
  | ViewUsage;
230
314
 
231
315
  PartUsage:
232
- 'part' name=ID (':' type=QualifiedName)?
316
+ isVariation?='variation'? 'part' name=ID (':' type=QualifiedName multiplicity=Multiplicity?)?
317
+ ('{' body+=UsageBodyMember* '}' | ';');
318
+
319
+ MessageUsage:
320
+ 'message' name=ID? 'of' itemType=QualifiedName 'from' source=FlowEnd 'to' target=FlowEnd
233
321
  ('{' body+=UsageBodyMember* '}' | ';');
234
322
 
235
323
  // SysML v2 `use case def` / `use case` share a single leading `use case` token
@@ -265,10 +353,14 @@ StateUsage:
265
353
  'state' name=ID ':' type=QualifiedName
266
354
  ('{' body+=UsageBodyMember* '}' | ';');
267
355
 
268
- // SysML v2 interface usage: `interface siData : Interface { … }`.
356
+ // SysML v2 interface usage, including the normative typed-connect form:
357
+ // `interface fuel : FuelInterface connect tank.port to engine.port { … }`.
269
358
  InterfaceUsage:
270
- 'interface' name=ID ':' type=QualifiedName
271
- ('{' body+=UsageBodyMember* '}' | ';');
359
+ 'interface' name=ID (':' type=QualifiedName)?
360
+ ( 'connect' source=ReferenceName 'to' target=ReferenceName
361
+ ('{' body+=UsageBodyMember* '}' | ';')
362
+ | ('{' body+=UsageBodyMember* '}' | ';')
363
+ );
272
364
 
273
365
  // ActionUsage supports both typed (action name : Type;) and composite
274
366
  // (action name { nested-actions, flows, successions }) forms.
@@ -336,6 +428,17 @@ ConnectionUsage:
336
428
  ConnectionEnd:
337
429
  endName=FeatureName '::>' ref=ReferenceName;
338
430
 
431
+ // The BASE FEATURE of a connection definition — `abstract connection derivations
432
+ // : Derivation[*];` in the OMG's DerivationConnections. It is not a link; it is
433
+ // the feature every usage of that definition subsets, and it is what a
434
+ // SemanticMetadata's `baseType` has to point at. Without one, `baseType` has
435
+ // nothing to name.
436
+ //
437
+ // The leading `abstract` is what keeps this out of ConnectionUsage's way: that
438
+ // rule always continues to `connect` or `{`, this one always ends at `;`.
439
+ AbstractConnectionUsage:
440
+ isAbstract?='abstract' 'connection' name=ID ':' type=QualifiedName multiplicity=Multiplicity? ';';
441
+
339
442
  // ─── Behavior: Action definition body ───────────────────────────────────────
340
443
  // Action defs can have in/out/inout parameters plus regular body members
341
444
 
@@ -369,8 +472,37 @@ ControlNodeUsage:
369
472
  // ─── Behavior: Flow connection usage ────────────────────────────────────────
370
473
  // Syntax: flow of ItemType from source.port to target.port ;
371
474
 
475
+ // A flow usage may carry a NAME and a BODY, both of which this production used
476
+ // to drop. The normative grammar is
477
+ // `FlowUsage = OccurrenceUsagePrefix 'flow' FlowDeclaration DefinitionBody`
478
+ // with `FlowDeclaration : UsageDeclaration ValuePart? ('of' …)`
479
+ // (SysML-textual-bnf.kebnf:829, :837) — so a conforming flow takes a name from
480
+ // its UsageDeclaration and owns attributes in its body like any other usage.
481
+ //
482
+ // Dropping them was a MEMO divergence, not a language limit, and it was
483
+ // load-bearing: an anonymous, attribute-less flow can carry no `id`, hold no
484
+ // latency budget, and be referred to by nothing, which is irreconcilable with
485
+ // the identification core every MEMO element rests on. That is the whole reason
486
+ // FunctionalExchange and ComponentExchange exist as part defs beside the flows
487
+ // they stand in for.
488
+ // `of <itemType>` is OPTIONAL, because it is optional in SysML v2. The pinned
489
+ // corpus writes untyped flows throughout — `flow from focus.image to
490
+ // shoot.image;` — and `syside check`, the compiler of record, accepts them
491
+ // (measured 2026-08-12). Requiring the item type here did not reject such a
492
+ // model: it failed to match the production, so the flow parsed to nothing and
493
+ // was dropped without a diagnostic. A relationship that silently does not
494
+ // exist is worse than one that fails loudly.
495
+ // The two-end shorthand — `flow supplierPort.fuelSupply to
496
+ // consumerPort.fuelSupply;` — drops `from` as well. The corpus uses it for
497
+ // port-to-port wiring, where naming the ends twice adds nothing. It takes no
498
+ // name and no item type: those forms all spell `from`, which is what keeps the
499
+ // two branches distinguishable.
372
500
  FlowConnectionUsage:
373
- 'flow' 'of' itemType=QualifiedName 'from' source=FlowEnd 'to' target=FlowEnd ';';
501
+ 'flow' (
502
+ name=ID? ('of' itemType=QualifiedName)? 'from' source=FlowEnd
503
+ | source=FlowEnd
504
+ ) 'to' target=FlowEnd
505
+ ('{' body+=UsageBodyMember* '}' | ';');
374
506
 
375
507
  FlowEnd:
376
508
  ref=DottedName;
@@ -396,9 +528,206 @@ SuccessionRef returns string:
396
528
 
397
529
  // ─── Behavior: Allocate usage ───────────────────────────────────────────────
398
530
  // Syntax: allocate actionUsage to partUsage ;
399
-
531
+ //
532
+ // The `allocation` prefix is the TYPED form — `AllocationUsage = 'allocation'
533
+ // UsageDeclaration UsageBody` (SysML-textual-bnf.kebnf:794), written in the
534
+ // corpus as
535
+ //
536
+ // allocation torqueGenAlloc : LogicalToPhysical allocate torqueGenerator to powerTrain;
537
+ //
538
+ // It is the same statement as bare `allocate` plus a name and an `allocation
539
+ // def` to type it, which is what carries MEMO's per-allocation distinctions
540
+ // (function allocation vs. deployment vs. build) without a private connection
541
+ // def per case. Folded into this rule rather than added as a sibling, because
542
+ // both forms end in the same `allocate … to …` and splitting them would make
543
+ // the alternatives ambiguous.
400
544
  AllocateUsage:
401
- 'allocate' source=ReferenceName 'to' target=ReferenceName ';';
545
+ ('allocation' name=ID? (':' type=QualifiedName)?)?
546
+ 'allocate' source=ReferenceName 'to' target=ReferenceName
547
+ ('{' body+=UsageBodyMember* '}' | ';');
548
+
549
+ // ─── Requirements: native satisfaction and verification ─────────────────────
550
+ //
551
+ // The two relations SysML v2 already provides for requirement traceability.
552
+ // MEMO spells them today as the `SatisfiedBy` / `VerifiedBy` connection defs;
553
+ // the language spells them as usages, and every conforming tool reads the
554
+ // language spelling. Both parse, and the model builder projects both onto the
555
+ // same trace edge, so a model may use either while the migration runs.
556
+ //
557
+ // `SatisfyRequirementUsage` (SysML-textual-bnf.kebnf:1470) declares the
558
+ // assertion prefix as `'assert' ('not')?`. The normative training files write
559
+ // the bare form — `satisfy vehicleSpecification by vehicle_design;`
560
+ // ("32. Requirements/Requirement Satisfaction.sysml") — so the prefix is
561
+ // optional here and `isNegated` records a negative satisfaction claim, which
562
+ // is the property a `connection def` cannot express at all.
563
+ //
564
+ // The `by` part is optional in the normative grammar: inside a requirement
565
+ // body the satisfying subject is inherited rather than restated.
566
+ SatisfyRequirementUsage:
567
+ (isAsserted?='assert' isNegated?='not'?)? 'satisfy' requirement=ReferenceName
568
+ ('by' satisfyingFeature=ReferenceName)?
569
+ ('{' body+=UsageBodyMember* '}' | ';');
570
+
571
+ // `RequirementVerificationMember` (SysML-textual-bnf.kebnf:1551) is a member of
572
+ // a requirement body — in practice the `objective` of a verification case:
573
+ //
574
+ // verification def VehicleMassTest {
575
+ // objective { verify vehicleMassRequirement; }
576
+ // }
577
+ //
578
+ // The verifying case is the enclosing element, not a written end, so the
579
+ // builder takes it from the containment.
580
+ RequirementVerificationMember:
581
+ 'verify' requirement=ReferenceName
582
+ ('{' body+=UsageBodyMember* '}' | ';');
583
+
584
+ // ─── ARCADIA mechanisms the language already spells ─────────────────────────
585
+ //
586
+ // Fourteen keywords MEMO had no production for, each one a mechanism MEMO
587
+ // spells privately as a `connection def` or a `part def` (plan §4). Every form
588
+ // below is taken from the normative BNF and checked against the training files
589
+ // that use it; none is a MEMO extension. Each has a builder path projecting the
590
+ // native usage onto the SAME trace edge MEMO's connection produces, so both
591
+ // spellings mean one thing while the migration runs.
592
+
593
+ // `PerformActionUsage = OccurrenceUsagePrefix 'perform' PerformActionUsageDeclaration
594
+ // ActionBody` (:948). One end is written, the other is the owner — the same
595
+ // shape as `verify`, with the ends swapped: `verify` names its source and owns
596
+ // its target, `perform` owns its source (the performer) and names its target.
597
+ //
598
+ // part actorPrescriber { perform oaPrescribe; }
599
+ // part camera { perform action takePhoto references takePicture; }
600
+ PerformActionUsage:
601
+ 'perform' (isAction?='action' name=ID (':' type=QualifiedName)? ('references' performed=ReferenceName)?
602
+ | performed=ReferenceName)
603
+ ('{' body+=UsageBodyMember* '}' | ';');
604
+
605
+ // `IncludeUseCaseUsage = OccurrenceUsagePrefix 'include' …` (:1572). A use case
606
+ // includes a sub-case; MEMO spells it `IncludesStep` / `Includes`.
607
+ IncludeUseCaseUsage:
608
+ 'include' (isUseCase?='use' 'case' name=ID (':' type=QualifiedName)?
609
+ | included=ReferenceName)
610
+ ('{' body+=UsageBodyMember* '}' | ';');
611
+
612
+ // `ExhibitStateUsage = OccurrenceUsagePrefix 'exhibit' …` (:1272). A component
613
+ // exhibits a state or mode; MEMO spells it `ExhibitsMode`.
614
+ ExhibitStateUsage:
615
+ 'exhibit' (isState?='state' name=ID (':' type=QualifiedName)?
616
+ | exhibited=ReferenceName)
617
+ ('{' body+=UsageBodyMember* '}' | ';');
618
+
619
+ // `SubjectUsage : ReferenceUsage = 'subject' UsageExtensionKeyword* Usage`
620
+ // (:1423) and `ObjectiveMember … 'objective' ObjectiveRequirementUsage` (:1523).
621
+ //
622
+ // The pair is what the standard uses instead of a verification link to a
623
+ // non-requirement: the verified thing becomes the case's SUBJECT and the
624
+ // requirement its OBJECTIVE, as in "34. Verification":
625
+ //
626
+ // verification def VehicleMassTest {
627
+ // subject testVehicle : Vehicle;
628
+ // objective { verify vehicleMassRequirement; }
629
+ // }
630
+ //
631
+ // That is what memo-native-requirement-relations decision 1 remodels 61 of 99
632
+ // VerifiedBy links onto, and it is also what makes that training file parse.
633
+ SubjectMember:
634
+ 'subject' name=MemberName (':' type=QualifiedName multiplicity=Multiplicity?)?
635
+ (bindingOp=('=' | ':>' | ':>>')
636
+ ('(' boundRefs+=ReferenceName (',' boundRefs+=ReferenceName)* ')'
637
+ | boundRefs+=ReferenceName))?
638
+ ('{' body+=UsageBodyMember* '}' | ';');
639
+
640
+ ObjectiveMember:
641
+ 'objective' name=ID? (':' type=QualifiedName)?
642
+ ('{' body+=UsageBodyMember* '}' | ';');
643
+
644
+ // `ActorUsage : PartUsage = 'actor' UsageExtensionKeyword* Usage` (:1454) and
645
+ // `StakeholderUsage : PartUsage = 'stakeholder' …` (:1460). ARCADIA operational
646
+ // analysis and ISO 42010; MEMO spells them `part def User` / `Actor` and
647
+ // `part def Stakeholder`.
648
+ ActorMember:
649
+ 'actor' name=MemberName (':' type=QualifiedName multiplicity=Multiplicity?)?
650
+ (bindingOp=('=' | ':>' | ':>>') boundRef=ReferenceName)?
651
+ ('{' body+=UsageBodyMember* '}' | ';');
652
+
653
+ StakeholderMember:
654
+ 'stakeholder' name=MemberName (':' type=QualifiedName multiplicity=Multiplicity?)?
655
+ (bindingOp=('=' | ':>' | ':>>') boundRef=ReferenceName)?
656
+ ('{' body+=UsageBodyMember* '}' | ';');
657
+
658
+ // `ConcernUsage = OccurrenceUsagePrefix 'concern' ConstraintUsageDeclaration
659
+ // RequirementBody` (:1497) and `FramedConcernMember … 'frame' FramedConcernUsage`
660
+ // (:1441). A viewpoint FRAMES a concern; MEMO spells that `FramesConcern` and
661
+ // `HasConcern`.
662
+ ConcernUsage:
663
+ 'concern' name=ID (':' type=QualifiedName)?
664
+ ('{' body+=UsageBodyMember* '}' | ';');
665
+
666
+ FramedConcernMember:
667
+ 'frame' (isConcern?='concern' name=ID (':' type=QualifiedName)?
668
+ | framed=ReferenceName)
669
+ ('{' body+=UsageBodyMember* '}' | ';');
670
+
671
+ // `Dependency = ( PrefixMetadataAnnotation )* 'dependency' DependencyDeclaration
672
+ // RelationshipBody` (:51), with `DependencyDeclaration = ( Identification 'from' )?
673
+ // client ( ',' client )* 'to' supplier ( ',' supplier )*` (:56).
674
+ //
675
+ // THIS ONE CHANGES METACLASS. A dependency is a Relationship, not a Connection:
676
+ // it has no ends to redefine, it takes n clients and n suppliers rather than a
677
+ // source and a target, and it is annotated by a PREFIX metadata (`#refinement`)
678
+ // rather than by a connection def's `metadata def`. So `Realizes` does not
679
+ // become an allocation-shaped row — it becomes `#refinement dependency a to b;`,
680
+ // and the registry and serializer both have to treat it differently.
681
+ //
682
+ // `Identification` may be empty, which is why `dependency from a to b;` and
683
+ // `dependency Named from a to b;` are both the same alternative, and
684
+ // `dependency a to b;` is the one without it.
685
+ Dependency:
686
+ (prefixMetadata+=PrefixMetadataAnnotation)*
687
+ 'dependency' (name=ID? 'from')?
688
+ clients+=ReferenceName (',' clients+=ReferenceName)*
689
+ 'to' suppliers+=ReferenceName (',' suppliers+=ReferenceName)*
690
+ ('{' body+=DocComment* '}' | ';');
691
+
692
+ // `#Name` — the standard's prefix form of a metadata application, distinct from
693
+ // the `@Name` postfix form MetadataApplication already covers. A dependency can
694
+ // only be annotated this way, and `#refinement` (ModelingMetadata.sysml:132) is
695
+ // the annotation that makes a dependency a refinement.
696
+ PrefixMetadataAnnotation:
697
+ '#' type=QualifiedName;
698
+
699
+ // `TransitionUsage = 'transition' ( UsageDeclaration 'first' )? FeatureChainMember
700
+ // … 'then' TransitionSuccessionMember ActionBody` (:1281). MEMO models this as
701
+ // `part def Transition` with String pseudo-references; the language puts it
702
+ // inside a `state def`, where source and target really are the states.
703
+ //
704
+ // The name is only writable with `first`, which is what disambiguates
705
+ // `transition initial then off;` (no name, `initial` is the source) from
706
+ // `transition off_to_starting first off … then starting;`.
707
+ // The optional type comes from `UsageDeclaration = Identification
708
+ // FeatureSpecializationPart?`, so `transition tStart : Transition first …` is
709
+ // the normative spelling of a transition classified by a definition. MEMO needs
710
+ // it: the builder resolves an element's kind from its written type and from
711
+ // nothing else, so an untyped transition would have to be given the kind
712
+ // `Transition` by a hardcoded name in TypeScript — which is the thing
713
+ // [memo-tools-interprets-ontology-drives] forbids.
714
+ TransitionUsage:
715
+ 'transition' (name=ID (':' type=QualifiedName)? 'first')? source=ReferenceName
716
+ ('accept' trigger=ReferenceName)?
717
+ ('if' guard=OrExpr)?
718
+ ('do' effect=ReferenceName)?
719
+ 'then' target=ReferenceName
720
+ ('{' body+=UsageBodyMember* '}' | ';');
721
+
722
+ // `VariantUsageMember : VariantMembership = MemberPrefix 'variant'
723
+ // VariantUsageElement` (:254). One alternative of a `variation` choice point —
724
+ // either a nested usage (`variant part transmissionManual : TransmissionManual;`)
725
+ // or a reference to an existing one (`variant manualTransmission;`).
726
+ VariantMember:
727
+ 'variant' (usageKind=('part' | 'attribute' | 'item' | 'action' | 'port' | 'ref'))? name=MemberName
728
+ (':' type=QualifiedName multiplicity=Multiplicity?)?
729
+ ('=' value=AttributeValue)?
730
+ ('{' body+=UsageBodyMember* '}' | ';');
402
731
 
403
732
  // Element references may be package-qualified (`a::b`) or feature-qualified
404
733
  // (`action.step`). Both forms occur in standard SysML relationship ends.
@@ -408,7 +737,23 @@ ReferenceName returns string:
408
737
  // ─── Body members ────────────────────────────────────────────────────────────
409
738
 
410
739
  DefinitionBodyMember:
411
- AttributeMember | PartMember | PortUsage | ItemUsage | ViewUsage | RefMember | RequireConstraintMember | MetadataApplication | DocComment;
740
+ AttributeMember | PartMember | PortUsage | ItemUsage | ViewUsage | RefMember | FeatureMembershipMember | RequireConstraintMember | RequirementVerificationMember | ArcadiaMember | MetadataApplication | DocComment;
741
+
742
+ // The fourteen native mechanisms, gathered once so both body rules stay
743
+ // readable and neither can drift out of step with the other.
744
+ ArcadiaMember:
745
+ PerformActionUsage
746
+ | IncludeUseCaseUsage
747
+ | ExhibitStateUsage
748
+ | SubjectMember
749
+ | ObjectiveMember
750
+ | ActorMember
751
+ | StakeholderMember
752
+ | ConcernUsage
753
+ | FramedConcernMember
754
+ | TransitionUsage
755
+ | VariantMember
756
+ | AllocateUsage;
412
757
 
413
758
  // ─── Constraint expression (KerML boolean subset — ADR-1-18) ─────────────────
414
759
  // Authored inside constraint def / requirement def bodies as:
@@ -451,8 +796,14 @@ PrimaryExpr infers ConstraintExpr:
451
796
  // Standard SysML v2 requires a redefinition operator (`redefines` / `:>>`) to bind a
452
797
  // value — the bare `name = value;` shorthand is non-standard and is not accepted.
453
798
  // Use `attribute redefines name = value;` (the form the serializer emits).
799
+ // StateUsage is a body member because a SysML v2 state machine OWNS its
800
+ // substates — nesting is the containment. MEMO could not parse a nested state
801
+ // while transitions were a part def wired to flat states by Composes edges;
802
+ // it landed when that reinvention was retired. TransitionUsage is NOT listed
803
+ // here: it already arrives through ArcadiaMember, and naming it twice makes
804
+ // the alternation ambiguous.
454
805
  UsageBodyMember:
455
- AttributeMember | PartMember | PortUsage | ItemUsage | RefMember | ViewUsage | FlowConnectionUsage | SuccessionUsage | ConnectionUsage | MetadataApplication | DocComment;
806
+ AttributeMember | PartMember | PortUsage | ItemUsage | RefMember | ViewUsage | FlowConnectionUsage | MessageUsage | SuccessionUsage | ConnectionUsage | SatisfyRequirementUsage | RequirementVerificationMember | ArcadiaMember | Dependency | MetadataApplication | StateUsage | DocComment;
456
807
 
457
808
  // ─── Attribute member ────────────────────────────────────────────────────────
458
809
  // Three forms:
@@ -475,11 +826,17 @@ UsageBodyMember:
475
826
  // theoretical once rules and policies started declaring typed attributes with
476
827
  // defaults. SysIDE is the compiler of record, so the grammar follows it.
477
828
 
829
+ // A fifth form is `default`, which supplies an overridable initial value where
830
+ // a bare `=` BINDS one. The difference is not cosmetic: a bound value cannot be
831
+ // redefined by a usage, so `= x` in a definition forbids every specialization
832
+ // from disagreeing. Any attribute a subtype may legitimately override has to be
833
+ // spelled `default`.
478
834
  AttributeMember:
479
- 'attribute' redefines?=('redefines' | ':>>')? name=MemberName
835
+ isVariation?='variation'? 'attribute' redefines?=('redefines' | ':>>')? name=MemberName
480
836
  (':' type=QualifiedName multiplicity=Multiplicity?
481
- ('=' value=AttributeValue ';' | '{' body+=UsageBodyMember* '}' | ';')
482
- | '=' value=AttributeValue ';'
837
+ (isDefault?='default'? '=' value=AttributeValue ';' | isDefault?='default' value=AttributeValue ';' | '{' body+=UsageBodyMember* '}' | ';')
838
+ | isDefault?='default'? '=' value=AttributeValue ';'
839
+ | isDefault?='default' value=AttributeValue ';'
483
840
  | '{' body+=UsageBodyMember* '}');
484
841
 
485
842
  AttributeValue:
@@ -506,9 +863,19 @@ SetLiteral:
506
863
  SetElement:
507
864
  value=QualifiedName | stringValue=STRING;
508
865
 
509
- // Enum literal reference: e.g. SeverityLevel::Catastrophic
866
+ // Enum literal reference (e.g. SeverityLevel::Catastrophic), or a metaclass
867
+ // cast. `x meta SysML::Usage` is the standard's MetadataAccessExpression: it
868
+ // yields the metaobject of `x` as an instance of the named metaclass, and it is
869
+ // how a SemanticMetadata binds its required `baseType`
870
+ // (`:>> baseType = derivations meta SysML::Usage`). Folded into this rule
871
+ // rather than added as a sibling alternative, because both start with a
872
+ // QualifiedName and only the trailing `meta` tells them apart.
873
+ // Also the bare feature-reference value (`ref :>> activeMode = a.b.c;`). A
874
+ // nested state is reached by a dotted path, so a value that names one needs
875
+ // the `.` tail; `::` alone only reaches package members, which is all MEMO
876
+ // needed while every state sat flat in a package.
510
877
  EnumValue:
511
- enumRef=QualifiedName;
878
+ enumRef=QualifiedName ('.' tail+=ID)* ('meta' metaclass=QualifiedName)?;
512
879
 
513
880
  // ─── Nested part member ──────────────────────────────────────────────────────
514
881
  // Four forms:
@@ -532,7 +899,7 @@ EnumValue:
532
899
  // feature, so every existing `:>` consumer is unaffected.
533
900
 
534
901
  PartMember:
535
- 'part'
902
+ isVariation?='variation'? 'part'
536
903
  (bindingOp=':>>' name=MemberName ('=' boundRef=QualifiedName)?
537
904
  | name=MemberName
538
905
  (':' type=QualifiedName multiplicity=Multiplicity?)?
@@ -545,13 +912,41 @@ PartMember:
545
912
  // ref function : SystemFunction[0..1]; (keyword-named reference)
546
913
  // ref item exchangedItem : ExchangeItem; (item-typed reference payload)
547
914
  // ref :>> definition = syringeDef; (redefining a reference to a value)
915
+ // ref vpLogical :> viewpointDefinition = logicalArchitectureViewpoint;
916
+ // (subset a feature and bind its value)
917
+ //
918
+ // The last form is the native spelling used by document views. `ref` is a
919
+ // reference feature, so it must support the same subsetting-and-value shape as
920
+ // `part`; accepting only the latter made the in-browser parser reject SysIDE-
921
+ // valid view declarations at `:>`.
548
922
 
549
923
  RefMember:
550
924
  'ref' (isItem?='item')? (redefines?=':>>')? name=FeatureName
551
925
  (':' isConjugated?='~'? type=QualifiedName multiplicity=Multiplicity?)?
552
- ('=' value=AttributeValue)?
926
+ ( (bindingOp=':>' boundRef=QualifiedName ('=' subsetValue=QualifiedName)?)
927
+ | ('=' value=AttributeValue)
928
+ )?
553
929
  ';';
554
930
 
931
+ // ─── Bare feature-membership member ──────────────────────────────────────────
932
+ // SysML v2 lets a definition body subset or redefine an inherited feature
933
+ // without restating its metaclass keyword. The standard library's own metadata
934
+ // defs are written that way and cannot be written any other way:
935
+ //
936
+ // :> annotatedElement : SysML::ConnectionDefinition;
937
+ // :>> baseType = derivations meta SysML::Usage;
938
+ //
939
+ // MEMO accepted only `attribute :>> name = value`, which covers redefinition of
940
+ // an attribute and nothing else — not subsetting, and not a non-attribute
941
+ // feature. `:>` is the form that matters here: `annotatedElement` is declared
942
+ // once per accepted metaclass, so it must SUBSET rather than redefine, or the
943
+ // second declaration would shadow the first.
944
+
945
+ FeatureMembershipMember:
946
+ (isRedefinition?=':>>' | ':>') feature=QualifiedName
947
+ (':' type=QualifiedName)? multiplicity=Multiplicity?
948
+ ('=' value=AttributeValue)? ';';
949
+
555
950
  // ─── Doc comment ─────────────────────────────────────────────────────────────
556
951
  // Captured as a single terminal to prevent hidden ML_COMMENT from consuming it
557
952
 
@@ -611,6 +1006,10 @@ hidden terminal ML_COMMENT: /\/\*[\s\S]*?\*\//;
611
1006
  // preventing conflict with ML_COMMENT for standalone /* ... */ comments.
612
1007
  terminal DOC_COMMENT: /doc\s+\/\*[\s\S]*?\*\//;
613
1008
 
1009
+ // A bracketed short name, e.g. `<derive>`. Whole-token so the inner word may be
1010
+ // a keyword. Cannot collide with the comparison operators: `<=` does not match
1011
+ // (a letter must follow `<`), and `a<b>c` is not valid MEMO in any position.
1012
+ terminal SHORT_NAME: /<[a-zA-Z_][a-zA-Z0-9_]*>/;
614
1013
  terminal ID: /[a-zA-Z_][a-zA-Z0-9_]*/;
615
1014
  // SysML v2 unrestricted name: any text in single quotes, used when a name would
616
1015
  // otherwise collide with a reserved word (e.g. enum 'verification';).