@g1cloud/entity-modeler-next 5.2.50 → 5.2.51

package/dist/agent/resolver.d.ts

@@ -82,20 +82,55 @@ export type ResolveError = {
  * `end.attributeRef` 셋이 EMBED 판정의 유일한 근거다 — `core/sharedColumn.sharedColumnScopeEntities`·
  * `ddl.ts` 평탄화·코드젠 `@Embedded` 가 전부 그것을 본다).
  *
- * ★resolver 에는 **EMBED 관계 생성 어휘가 없다**(AA-5 S3 미구현). 그래서 통과시키면 *항상* 「스테레오타입은
- * 임베더블인데 관계는 일반」 형상이 만들어지고, 그 형상은 **아무도 신호하지 않는다**: 공유 통화 스코프가
- * 자기 자신으로 좁아져 owner 통화 컬럼을 `SHARED_REF` 로 고를 수 없고(GUI picker 후보 0 = 사용자에겐
- * 「리졸빙 안 됨」으로만 보인다) DDL 은 컬럼을 평탄화하지 않으며 코드젠은 `@Embedded` 를 내지 않는다.
- * 실측(2026-08-25 프로덕션): 이 형상 4건 중 1건이 증상으로 드러나고 3건은 잠복이었다.
+ * ★★**2026-09-13 — 범위가 «to 가 아니라 from» 으로 좁았다**(AA-5 S3 구현). 종전엔 end 중 하나라도
+ * 임베더블이면 전부 거부했는데, 그때의 근거는 *「resolver 에 EMBED 관계 생성 어휘가 없다」* 였고 그래서
+ * 통과시키면 *항상* 「스테레오타입은 임베더블인데 관계는 일반」 무신호 형상이 됐다(공유 통화 스코프가
+ * 자기 자신으로 좁아져 `SHARED_REF` 후보 0 · DDL 평탄화 없음 · 코드젠 `@Embedded` 없음 ·
+ * 실측 2026-08-25 프로덕션 4건 중 1건 증상·3건 잠복). **그 어휘가 생겼으므로 거부가 방출로 바뀌었다** —
+ * 종전 주석이 *「어휘가 생기면 거부 대신 EMBED 방출로 바뀔 자리」* 라 예고한 그 자리다.
  *
- * ⇒ GUI 는 이 조작을 애초에 EMBED 로 분기한다(`DiagramCanvas.vue` 연결 핸들러·`editor/association.ts`).
- *   같은 불변식을 op 경로에서도 지킨다 — 어휘가 생기면(AA-5 S3) 거부 대신 EMBED 방출로 바뀔 자리다.
+ * ⇒ 남는 거부는 **`from` 만 임베더블**인 경우뿐이다. 그것은 임베더블을 **FK 부모**로 세우는 것이고
+ *   임베더블엔 테이블도 PK 도 없어 전파할 식별자가 없다 ⇒ 만들 관계가 존재하지 않는다.
+ *   (`to` 가 임베더블이면 — `from` 이 임베더블이어도 — EMBED 이고, 그 연쇄 임베드는 정당하다.)
  */
  | {
     code: 'embeddable-relation-unsupported';
     opIndex: number;
     handle: AssocHandle;
 }
+/**
+ * EMBED 로 분기된 `association.add` 인데 `AssocSpec` 에 **임베드에 성립하지 않는 필드**가 실려 있다.
+ *
+ * ★**조용히 무시하지 않는 이유** — 이 리포가 반복해 대가를 치른 「조용한 반쪽 적용」이다. `identifying`
+ * (식별 관계 = 부모 PK 를 자식 PK 로 전파)과 `composition`·`fromMultiplicity` 는 **FK 관계의 축**이고
+ * 임베드엔 대응물이 없다(임베드의 소유 관계는 `end2.composition=true` 고정이고, 카디널리티 권위는
+ * **임베더블을 가리키는 end** 하나다 — `editor/association.setEmbedCardinality` 의 결정 3).
+ * 보내 놓고 안 먹히면 호출자는 *「먹었다」* 고 믿는다 ⇒ 거부해서 그 자리를 지목한다.
+ *
+ * ⚠️**`toMultiplicity` 는 여기 들어오지 않는다** — 그쪽이 곧 카디널리티 축이다(단일 `@Embedded` ↔
+ *   컬렉션 `@ElementCollection`). 부적합이 아니라 **유일한 적용 필드**다.
+ */
+ | {
+    code: 'embed-spec-inapplicable';
+    opIndex: number;
+    handle: AssocHandle;
+    fields: string[];
+}
+/**
+ * 임베더블이 **자기 자신을 임베드**하려 했다 — 구조적으로 성립하지 않는다
+ * (`class Addr { @Embedded Addr addr; }` = 무한 재귀).
+ *
+ * ★**연쇄 임베드(임베더블 → «다른» 임베더블)와 갈라야 한다** — 그쪽은 **정당하고 실재한다**
+ * (프로덕션 v2 43문서 실측: 연쇄 **3** · 자기 임베드 **0** — `ApplyPriceDcPromo.dcRule → PromoDcRule` 등).
+ * ⚠️**GUI 는 임베더블↔임베더블을 통째로 막는다**(`DiagramCanvas.handleConnect` 의 `if (srcEmbed && tgtEmbed) return`)
+ * ⇒ 그 실측 3건은 GUI 로 만들 수 없는 형상이고, **그쪽이 갭**이다(op·레거시 로드 경로로 유입).
+ * 여기서 자기 임베드«만» 막는 것은 그 갭을 따라가지 않기 위해서다 — 막을 것은 재귀뿐이다.
+ */
+ | {
+    code: 'embed-self-unsupported';
+    opIndex: number;
+    handle: AssocHandle;
+}
 /**
  * `association.add` 의 end 중 하나가 `SERIALIZED_TYPE` — **거부 사유가 임베더블과 다르다**.
  *
@@ -632,6 +667,41 @@ export type ResolveError = {
         from: string;
         to: string;
     };
+}
+/**
+ * `attribute.update` 가 **`NORMAL` 속성의 컬럼을 둘 이상으로** 만들려 했다 — 컬럼 «개수» 축 가드(AA-5 S5).
+ *
+ * ★★**형제 게이트 둘이 막던 것과 «같은 상태»인데 문이 달랐다**: `attribute-attrtype-unsupported` 는
+ * `attrType` 을 직접 준 경우를, `attribute-type-conversion-unsupported` 는 `type` 만 준 경우를 막는다.
+ * 그런데 **`dbAttrs` 만 늘리면** `attrType`·`type` 이 그대로라 **둘 다 비켜간다** — 실증(2026-09-13):
+ * ⓒ`patch.dbAttrs` 배열 통째 교체와 ⓑdotted `dbAttrs.<없는 i>.<field>` 가 **둘 다 `ok:true`** 였다.
+ * 그 결과 상태를 하류가 각자 다르게 읽는다: **DDL 은 2컬럼을 내고** 코드젠은 **1필드**만 내며
+ * (두 번째 컬럼이 산출에서 사라진다) 검증은 **신고 0**이고, GUI 는 `hasColumnSlots` 가 false 라
+ * **화면에 보이지도 않는다**. 게다가 사용자가 그 속성을 편집하면 `useAttributeEditing.setDb` 가
+ * `dbAttrs:[next]` 로 **통째 교체** = 두 번째 컬럼이 **조용히 삭제**된다 ⇒ 진입만 있고 출구가 파괴적인
+ * **단방향 트랩**이다(메모리 `affordance-must-be-reversible`).
+ *
+ * ⇒ **GUI 에 없는 조작이므로 막는 것이 패리티다**(GUI 는 NORMAL 을 단일 컬럼 블록으로만 편집한다).
+ * ★**그리고 이제 대안이 실재한다** — 다중 컬럼이 필요하면 **임베더블 + EMBED 관계**(AA-5 S3)가 그 자리다.
+ *   이 가드를 S3 «뒤»에 세운 이유가 그것이다: 먼저 세웠다면 표현력 부족을 가드로 덮는 것이었다.
+ * ⚠️판정은 **patch 적용 «후»** 의 `attrType` 으로 한다(계획 diff 규율 — 메모리
+ *   `plan-diff-judgment-uses-post-plan-state`). ★★**다만 그 읽기는 «현재» 불활성이다** — 민감도로
+ *   실증했다(2026-09-13: 적용 «전» 으로 되돌려도 전량 green). `patch.attrType` 을 세우는 경로가 둘뿐이고
+ *   **둘 다 여기 안 닿는다**: ⓐ사용자 직접 지정은 `attribute-attrtype-unsupported` 가 **먼저** 거부하고
+ *   ⓑresolver 내부 in-place 값 타입 전환은 **컬럼 개수를 보존**한다(`columnPreservingValueTypeEntry`).
+ *   ⇒ 선례(`fe47316`)대로 처방은 *「가드를 단순화」* 가 아니라 **「불활성의 전제를 테스트로 고정」** 이고,
+ *   그 앵커가 `resolver.test.ts` 의 «in-place 값 타입 전환은 컬럼 개수를 보존한다» 다. ⓑ가 컬럼을
+ *   늘리게 되면 그 테스트가 red 가 되고 이 post-patch 읽기가 **살아난다**.
+ */
+ | {
+    code: 'attribute-column-count-unsupported';
+    opIndex: number;
+    entity: Handle;
+    handle: Handle;
+    /** patch 적용 후 attrType(판정 기준). */
+    attrType: string;
+    current: number;
+    requested: number;
 };
 export type ResolveNotice = {
     code: 'inherited-slot-override';