@g1cloud/entity-modeler-next 5.2.1 → 5.2.3

package/dist/agent/resolver.d.ts

@@ -309,6 +309,55 @@ export type ResolveError = {
     entity: Handle;
     keys: string[];
 }
+/**
+ * ── `*-spec-unknown-key` 계열 — add op 의 `spec` 에 그 spec 이 갖지 않는 키 ──
+ *
+ * ★**patch 계열과 실패 모드가 다르다.** patch 는 통과하면 호스트가 **blind-write** 해 오염을 «만든다».
+ * spec 은 반대로 resolver 가 명명된 필드만 골라 담으므로 미지 키가 **조용히 사라진다** — 호출자는
+ * `ok` 를 받고 그 값이 반영됐다고 믿는다(무신호 소실). 그래서 둘 다 거부하지만 근거가 갈린다.
+ *
+ * ★**스키마는 이미 `additionalProperties: false` 로 닫아 두었다** — 이 거부는 새 제약이 아니라
+ *   **선언된 계약의 집행**이다. 스키마는 LLM 에게 주는 tool 정의일 뿐 게이트가 아니고(호스트
+ *   symbolic-ops 라우트는 body 를 스키마 검증 없이 resolver 로 넘긴다), 그래서 resolver 가 유일한 게이트다.
+ *
+ * ★발견 경위(2026-08-29): `entity.add` 에 `serialization`(직렬화 컨테이너)을 주면 `ok:true` 인데 값이
+ *   사라졌다. 같은 필드를 `entity.update` 로 주면 `entity-patch-unknown-key` 로 **거부**됐다 — 즉
+ *   **add 는 삼키고 update 는 거부**하는 비대칭이었다. 어휘를 연 뒤에도(위 `serialization`) 오탈자·
+ *   미래 필드가 같은 자리로 사라지므로 계열 자체를 신설한다.
+ */
+ | {
+    code: 'entity-spec-unknown-key';
+    opIndex: number;
+    handle: Handle;
+    keys: string[];
+} | {
+    code: 'attribute-spec-unknown-key';
+    opIndex: number;
+    entity: Handle;
+    handle: Handle;
+    keys: string[];
+} | {
+    code: 'index-spec-unknown-key';
+    opIndex: number;
+    entity: Handle;
+    handle: Handle;
+    keys: string[];
+} | {
+    code: 'operation-spec-unknown-key';
+    opIndex: number;
+    entity: Handle;
+    handle: Handle;
+    keys: string[];
+} | {
+    code: 'association-spec-unknown-key';
+    opIndex: number;
+    handle: AssocHandle;
+    keys: string[];
+} | {
+    code: 'group-spec-unknown-key';
+    opIndex: number;
+    keys: string[];
+}
 /**
  * entity.add의 논리명이 모델에 이미 있는 엔티티와 충돌. 통과시키면 **도구가 스스로 `CHK-NAME-3`(error)
  * 상태를 만든다**(CC-5 교훈: 엔진이 검증 error 상태를 생성하지 않는다). 더 나쁜 건 같은 배치의 형제
@@ -455,4 +504,10 @@ export interface ResolverOptions {
      */
     embeddableCatalog?: EmbeddableCatalog;
 }
+export declare const ENTITY_SPEC_KEYS: ReadonlySet<string>;
+export declare const ATTR_SPEC_KEYS: ReadonlySet<string>;
+export declare const INDEX_SPEC_KEYS: ReadonlySet<string>;
+export declare const OPERATION_SPEC_KEYS: ReadonlySet<string>;
+export declare const ASSOC_SPEC_KEYS: ReadonlySet<string>;
+export declare const GROUP_SPEC_KEYS: ReadonlySet<string>;
 export declare function resolveSymbolicOps(model: LogicalModel, ops: SymbolicOp[], options?: ResolverOptions): ResolveResult;

package/dist/agent/symbolicOp.d.ts

@@ -1,4 +1,4 @@
-import { ClassStereotype, MultiLangText, Multiplicity, OperationVisibility } from '../core/types';
+import { ClassStereotype, Entity, MultiLangText, Multiplicity, OperationVisibility } from '../core/types';
 /**
  * 요소 지정 핸들 — modelId 대신 이름/물리명.
  * 엔티티: 물리명(`table.physicalName`) 우선, 논리명(`name`) 보조 — 논리명은 모델 내 중복 허용(CHK-NAME-3)이라 모호 가능.
@@ -55,6 +55,15 @@ export interface EntitySpec {
     indexes?: IndexSpec[];
     /** inline 도메인 메서드 — 배열 순서가 곧 `order`. */
     operations?: OperationSpec[];
+    /**
+     * 직렬화 축 — 이 타입이 **소비될 때의 컨테이너**(`stereotype: 'SERIALIZED_TYPE'` 일 때만 의미).
+     * 타입을 SoT 로 두는 근거는 `core/types.ts` `Entity.serialization` 주석(요소 타입당 컨테이너가 하나로
+     * 고정된다는 실측). 미지정 = 컬렉션이 아닌 단일 값.
+     *
+     * ★**신규 엔티티는 add 시점에 줘야 한다** — 같은 배치의 `entity.update` 는 갓 만든 엔티티에 닿지 못한다
+     * (pending-entity-ref). `useVersion` 과 같은 이유·같은 처방이다.
+     */
+    serialization?: Entity['serialization'];
 }
 /** attribute.add 페이로드 — resolver가 modelId 발급 + dbAttr 골격 조립. */
 export interface AttrSpec {

package/dist/editor/commandPlans.d.ts

@@ -1,6 +1,6 @@
 import { Command, EditorState } from '../command/types';
 import { ReconcilePlan } from '../core/propagation';
-import { Attribute, DbColumn, Entity, LogicalModel, ModelId, Point } from '../core/types';
+import { Attribute, ClassStereotype, DbColumn, Entity, LogicalModel, ModelId, Point } from '../core/types';
 /**
  * 한 조작이 지우는 속성의 누산기 — 인덱스 컬럼 정리를 **조작당 한 번**만 방출하기 위한 것.
  *
@@ -96,6 +96,23 @@ export declare function embedSlotRemovalCommands(logical: LogicalModel, entityId
  * futureLogical은 트리거 변경이 이미 반영된 상태여야 한다(construction 시점 계획 고정).
  */
 export declare function childReconcileWithCascade(futureLogical: LogicalModel, childIds: readonly ModelId[], removed: RemovedAttributes): Command[];
+/**
+ * **컬럼 축이 사라질 때 그 축의 «모든» 필드를 정리**하는 서브명령 — 직렬화 타입 전환 전용.
+ *
+ * ★**왜 함수로 뽑았나**: 전환은 두 경로로 들어온다 — 일반 엔티티에서 오는 `enteringValueType` 과
+ * **임베더블에서 오는 `betweenValueTypes`**. 처음엔 전자에만 정리를 달았고, 그 결과 실제 마이그레이션의
+ * 주 경로(임베더블 → 직렬화 타입)가 **컬럼·테이블을 그대로 달고 전환**됐다(2026-08-29 프로덕션 실측:
+ * `CartGift` 가 `table=cart_gift` · 속성 5개 전부 1컬럼을 유지한 채 `SERIALIZED_TYPE` 이 됐다).
+ * ⇒ 「축이 사라지면 그 축의 모든 필드를 정리」 규율의 **재발이고, 이번엔 필드가 아니라 «분기»를 빠뜨린
+ * 형태**다. 한 함수로 모아 두 분기가 같은 것을 쓰게 한다.
+ *
+ * ★대상은 **컬럼 축뿐**(`isColumnlessStereotype`) — 임베더블은 owner 테이블로 평탄화돼 **실제로 컬럼을
+ * 가지므로** 지우면 안 된다. 값 타입 축(테이블·PK)은 둘이 공유하지만 컬럼 축은 갈리는 자리다.
+ *
+ * @param removedIds 이 조작이 «이미» 제거한 속성(FK reconcile 산물) — 판정은 계획 **적용 후** 상태로
+ *   해야 한다(memory `plan-diff-judgment-uses-post-plan-state`). 없으면 빈 집합.
+ */
+export declare function columnAxisCleanupCommands(entity: Entity, to: ClassStereotype, removedIds?: ReadonlySet<ModelId>): Command[];
 export declare function flattenEmbeddableColumns(embeddable: Entity): DbColumn[];
 /**
  * 임베더블 → 일반 엔터티 역전환의 부수 명령(stereotype update 명령에 합성).