docs(misc): 추가 잔존 영역 옛 명명 정리 (영/한)

코드(Src/.cs)는 이미 신규 명명 완료(잔존 0건). 문서에 잔존하던 옛 이름과
사용자 정의 nested class 옛 표준 이름("DomainErrors" → "Domain")을 정리.

대상:
- design-philosophy.mdx: 산문 "DomainErrors are auto-generated"
  → "domain errors are auto-generated"
- spec/02-value-object.md (영/한): NestedErrorsClassName 값을 "Domain"으로
  정정. "변경 예정" 표현 제거 (이미 적용됨)
- guides/testing/16-testing-library.md (영/한): architecture test에서
  RequireNestedClassIfExists("DomainErrors", ...) → "Domain"
- guides/appendix/A04-architecture-rules-coverage.md (KR): 표 갱신
- tutorials/functional-valueobject/appendix/B-type-selection-guide.md (영/한):
  체크리스트 항목 갱신
- tutorials/functional-valueobject/part1/15-validation-fluent (영/한):
  출력 prefix 표기
- tutorials/functional-valueobject/part1/16-architecture-test (영/한):
  사용자 정의 nested class 패턴 인용 + IValueObject.DomainErrorsNestedClassName
  → IValueObject.ArchTestContract.NestedErrorsClassName
- tutorials/functional-valueobject/part3/08-architecture-test (영/한): 동
- 한글 조사 앞 DomainErrors(가/를/의/로/는/와) 정정

Framework testing helper 메서드 이름(ShouldBeDomainError, ShouldHaveDomainErrors,
ShouldHaveOnlyDomainError 등)은 코드 측 메서드 이름이라 그대로 유지. 13/14
학습 흐름 본문 재작성은 별도 트랙(다음 커밋).

Author: hhko

Docs.Site/src/content/docs/design-philosophy.mdx

@@ -31,7 +31,7 @@ public abstract class AbstractValueObject : IValueObject, IEquatable<AbstractVal
 Validation rules are defined in a single Value Object location, and `ValidationRules<T>` chaining automatically generates error codes for each condition. The following is a Value Object representing an email address. The `Fin<Email>` returned by `Create` contains an `Email` instance for valid input or an error code for invalid input. No exceptions are thrown, and the possibility of validation logic being scattered is structurally eliminated.
 
 ```csharp
-// On validation failure, condition-specific DomainErrors are auto-generated:
+// On validation failure, condition-specific domain errors are auto-generated:
 //   "Domain.Email.Null", "Domain.Email.Empty",
 //   "Domain.Email.TooLong", "Domain.Email.InvalidFormat"
 public sealed partial class Email : SimpleValueObject<string>

Docs.Site/src/content/docs/guides/testing/16-testing-library.md

@@ -741,8 +741,8 @@ public void ValueObject_ShouldSatisfy_ImmutabilityRules()
                 .RequireStatic()
                 .RequireReturnType(typeof(Validation<,>)));
 
-            // DomainErrors nested class validation (only if exists)
-            @class.RequireNestedClassIfExists("DomainErrors", domainErrors =>
+            // Domain nested class validation (only if exists)
+            @class.RequireNestedClassIfExists("Domain", domainErrors =>
             {
                 domainErrors
                     .RequireInternal()

Docs.Site/src/content/docs/ko/guides/appendix/A04-architecture-rules-coverage.md

@@ -168,7 +168,7 @@ API 요약에서 사용 가능한 검증 도구를 확인했습니다. 이제 
 | `IValueObject` 인터페이스 구현 | 05a | ⚠️ | ArchUnitNET 필터: `.ImplementInterface(typeof(IValueObject))` |
 | `IEquatable<>` 구현 | 05a | ✅ | `RequireImplements(typeof(IEquatable<>))` |
 | `SimpleValueObject<T>` 또는 `ValueObject` 상속 | 05a | ✅ | `RequireInherits(typeof(SimpleValueObject<>))` |
-| 중첩 `DomainErrors` 클래스 규칙 | 08b | ✅ | `RequireNestedClassIfExists("DomainErrors", ...)` |
+| 중첩 `Domain` 클래스 규칙 | 08b | ✅ | `RequireNestedClassIfExists("Domain", ...)` |
 | implicit operator 정의 | 05a | 🔧 | `DelegateArchRule`: `op_Implicit` 메서드 존재 확인 |
 | `ValidationRules<T>` 사용 | 05a | ❌ | 소스 코드 분석 필요 (IL에서 호출 패턴 추적 불가) |
 | `CreateFromValidation()` 패턴 사용 | 05a | ❌ | 소스 코드 분석 필요 |
@@ -233,8 +233,8 @@ API 요약에서 사용 가능한 검증 도구를 확인했습니다. 이제 
 
 | 규칙 | 출처 | 검증 가능 | 사용 API / 불가 사유 |
 |------|------|----------|---------------------|
-| 중첩 `DomainErrors` 클래스 (internal sealed) | 08b | ✅ | `RequireNestedClassIfExists("DomainErrors", n => n.RequireInternal().RequireSealed())` |
-| DomainErrors 메서드 (public static, Error 반환) | 08b | ✅ | `.RequireAllMethods(m => m.RequireStatic().RequireReturnType(typeof(Error)))` |
+| 중첩 `Domain` 클래스 (internal sealed) | 08b | ✅ | `RequireNestedClassIfExists("Domain", n => n.RequireInternal().RequireSealed())` |
+| Domain 메서드 (public static, Error 반환) | 08b | ✅ | `.RequireAllMethods(m => m.RequireStatic().RequireReturnType(typeof(Error)))` |
 | `DomainError.For<T>()` 팩토리 패턴 사용 | 08a | ❌ | 소스 코드 분석 필요 (메서드 본문의 호출 패턴) |
 | 에러 코드 형식 (`Domain.Type.Name`) | 08a | ❌ | 런타임 검증 필요 (단위 테스트로 검증) |
 | Custom 에러 타입이 sealed record | 08b | 🔧 | `DelegateArchRule`: 특정 네임스페이스의 Error 파생 타입 검사 |

Docs.Site/src/content/docs/ko/guides/testing/16-testing-library.md

@@ -741,8 +741,8 @@ public void ValueObject_ShouldSatisfy_ImmutabilityRules()
                 .RequireStatic()
                 .RequireReturnType(typeof(Validation<,>)));
 
-            // DomainErrors 중첩 클래스 검증 (존재하는 경우만)
-            @class.RequireNestedClassIfExists("DomainErrors", domainErrors =>
+            // Domain 중첩 클래스 검증 (존재하는 경우만)
+            @class.RequireNestedClassIfExists("Domain", domainErrors =>
             {
                 domainErrors
                     .RequireInternal()

Docs.Site/src/content/docs/ko/spec/02-value-object.md

@@ -65,7 +65,7 @@ public interface IValueObject
         public const string CreateMethodName = "Create";
         public const string CreateFromValidatedMethodName = "CreateFromValidated";
         public const string ValidateMethodName = "Validate";
-        public const string NestedErrorsClassName = "DomainErrors";
+        public const string NestedErrorsClassName = "Domain";
     }
 }
 ```
@@ -79,7 +79,7 @@ public interface IValueObject
 | `CreateMethodName` | `"Create"` | 팩토리 메서드 이름 규약 |
 | `CreateFromValidatedMethodName` | `"CreateFromValidated"` | 사전 검증된 값의 팩토리 메서드 이름 규약 |
 | `ValidateMethodName` | `"Validate"` | 검증 전용 메서드 이름 규약 |
-| `NestedErrorsClassName` | `"DomainErrors"` | 중첩 에러 클래스 이름 규약 (1.0.0-alpha.4에서 `"Domain"`으로 변경 예정) |
+| `NestedErrorsClassName` | `"Domain"` | 중첩 에러 클래스 이름 규약 |
 
 ---
 

Docs.Site/src/content/docs/ko/tutorials/functional-valueobject/appendix/B-type-selection-guide.md

@@ -337,7 +337,7 @@ public sealed class OrderStatus : SmartEnum<OrderStatus, string>, IValueObject
 - [ ] 타입이 sealed로 선언되었는가?
 - [ ] public 생성자 대신 팩토리 메서드(Create)를 사용하는가?
 - [ ] 검증 로직이 Create 메서드에 있는가?
-- [ ] DomainErrors 내부 클래스가 있는가?
+- [ ] Domain 내부 클래스가 있는가?
 - [ ] 불변성이 보장되는가?
 - [ ] 필요한 경우 암시적 변환 연산자가 있는가?
 - [ ] ToString()이 적절히 오버라이드되었는가?

Docs.Site/src/content/docs/ko/tutorials/functional-valueobject/part1-valueobject-concepts/15-validation-fluent/index.md

@@ -124,7 +124,7 @@ public static Validation<Error, string> Validate(string value) =>
 
 ### 자동 에러 코드 생성
 
-`Validate<T>`는 `DomainErrors.{ValueObjectName}.{ErrorTypeName}` 형식의 에러 코드를 자동으로 생성합니다.
+`Validate<T>`는 `Domain.{ValueObjectName}.{ErrorTypeName}` 형식의 에러 코드를 자동으로 생성합니다.
 
 ```csharp
 // 검증 코드 → 생성되는 에러 코드

Docs.Site/src/content/docs/ko/tutorials/functional-valueobject/part1-valueobject-concepts/16-architecture-test/index.md

@@ -16,7 +16,7 @@ title: "아키텍처 테스트"
 
 ## 왜 필요한가?
 
-C#의 제네릭 제약이나 인터페이스만으로는 모든 값 객체가 동일한 메서드 시그니처를 갖도록 강제할 수 없습니다. 예를 들어, IValueObject 인터페이스에서 Create 메서드를 정의할 수는 있지만 public static이어야 한다는 규칙까지 강제하기는 어렵습니다. 개발자가 실수로 Create 메서드를 private으로 만들거나, sealed를 누락하거나, DomainErrors 클래스 구조를 다르게 작성할 수 있고, 이런 문제는 코드 리뷰로 잡기에는 번거롭고 누락되기 쉽습니다.
+C#의 제네릭 제약이나 인터페이스만으로는 모든 값 객체가 동일한 메서드 시그니처를 갖도록 강제할 수 없습니다. 예를 들어, IValueObject 인터페이스에서 Create 메서드를 정의할 수는 있지만 public static이어야 한다는 규칙까지 강제하기는 어렵습니다. 개발자가 실수로 Create 메서드를 private으로 만들거나, sealed를 누락하거나, Domain 클래스 구조를 다르게 작성할 수 있고, 이런 문제는 코드 리뷰로 잡기에는 번거롭고 누락되기 쉽습니다.
 
 아키텍처 테스트를 도입하면 컴파일 타임에 강제할 수 없는 설계 규칙을 CI 파이프라인에서 자동으로 검증할 수 있습니다.
 
@@ -60,12 +60,12 @@ IValueObject 인터페이스를 구현하는 모든 클래스가 특정한 구
 
 ### 도메인 에러 규칙 검증
 
-DomainErrors 중첩 클래스가 있는 값 객체에 대해, 해당 클래스가 올바른 구조를 갖추고 있는지 검증합니다. 모든 값 객체에 DomainErrors가 필수는 아니므로 `RequireNestedClassIfExists`로 선택적으로 검증합니다.
+Domain 중첩 클래스가 있는 값 객체에 대해, 해당 클래스가 올바른 구조를 갖추고 있는지 검증합니다. 모든 값 객체에 Domain이 필수는 아니므로 `RequireNestedClassIfExists`로 선택적으로 검증합니다.
 
 ```csharp
-// DomainErrors 중첩 클래스 규칙 검증
+// Domain 중첩 클래스 규칙 검증
 @class
-    .RequireNestedClassIfExists("DomainErrors", domainErrors =>
+    .RequireNestedClassIfExists("Domain", domainErrors =>
     {
         domainErrors
             .RequireInternal()                          // internal 클래스
@@ -152,9 +152,9 @@ public void ValueObject_ShouldSatisfy_Rules()
                     .RequireReturnType(typeof(Validation<,>)))
                 .RequireImplements(typeof(IEquatable<>));
 
-            // DomainErrors 중첩 클래스 규칙
+            // Domain 중첩 클래스 규칙
             @class
-                .RequireNestedClassIfExists(IValueObject.DomainErrorsNestedClassName, domainErrors =>
+                .RequireNestedClassIfExists(IValueObject.ArchTestContract.NestedErrorsClassName, domainErrors =>
                 {
                     domainErrors
                         .RequireInternal()
@@ -216,15 +216,15 @@ public void ValueObject_ShouldSatisfy_Rules()
 }
 ```
 
-### Q2: DomainErrors 중첩 클래스가 선택적(IfExists)으로 검증되는 이유는?
+### Q2: Domain 중첩 클래스가 선택적(IfExists)으로 검증되는 이유는?
 
-모든 값 객체가 DomainErrors를 가져야 하는 것은 아닙니다. 단순한 값 객체는 복잡한 검증 로직이 없어 DomainErrors가 불필요할 수 있습니다. `RequireNestedClassIfExists`는 DomainErrors가 있는 값 객체에만 올바른 구조를 강제하고, 없는 값 객체는 검증을 건너뜁니다.
+모든 값 객체가 Domain을 가져야 하는 것은 아닙니다. 단순한 값 객체는 복잡한 검증 로직이 없어 Domain이 불필요할 수 있습니다. `RequireNestedClassIfExists`는 Domain이 있는 값 객체에만 올바른 구조를 강제하고, 없는 값 객체는 검증을 건너뜁니다.
 
 ```csharp
 // 복잡한 검증이 필요한 값 객체
 public sealed class Price : ComparableSimpleValueObject<decimal>
 {
-    internal static class DomainErrors  // DomainErrors 존재
+    internal static class Domain  // Domain 존재
     {
         public static Error Negative(decimal value) => ...;
     }
@@ -233,13 +233,13 @@ public sealed class Price : ComparableSimpleValueObject<decimal>
 // 단순한 값 객체
 public sealed class Currency : SmartEnum<Currency, string>
 {
-    // DomainErrors 없음 - 검증 건너뜀
+    // Domain 없음 - 검증 건너뜀
 }
 
 // 아키텍처 테스트: 선택적 검증
-@class.RequireNestedClassIfExists("DomainErrors", domainErrors =>
+@class.RequireNestedClassIfExists("Domain", domainErrors =>
 {
-    // DomainErrors가 있으면 이 규칙들을 적용
+    // Domain이 있으면 이 규칙들을 적용
     domainErrors.RequireInternal().RequireSealed();
 });
 ```