diff --git a/superpowers/plans/2026-06-04-shopee-outbound-api-wes-mapping.md b/superpowers/plans/2026-06-04-shopee-outbound-api-wes-mapping.md
index c4ac3d4..ee6e632 100644
--- a/superpowers/plans/2026-06-04-shopee-outbound-api-wes-mapping.md
+++ b/superpowers/plans/2026-06-04-shopee-outbound-api-wes-mapping.md
@@ -635,7 +635,7 @@ Convert WES `ResponseMessage` back to Shopee response shape:
 [retcode: 0, message: 'success', data: rsp.data ?: [:]]
 ```
 
-On WES business error, map to the configured Shopee error code and message. Do not expose WES stack traces.
+On WES business error, do not implement final Shopee `retcode` mapping yet. Return a generic Shopee failure shape, keep the WES message sanitized, and log the original WES error for later mapping design. Do not expose WES stack traces.
 
 - [ ] **Step 4: Add outbound call method**
 
@@ -889,8 +889,9 @@ POST /api/v2/automation/tovendor/inventory/racktransfer/create_rt_order
 
 Failure handling:
 
-- For retryable Shopee errors `-10013099` or timeout, record process history and let existing retry infrastructure retry the sync.
-- For non-retryable errors `-10013001`, `-10013023`, `-10013049`, `-10013098`, record the response and block/flag the transfer order according to the current WES transfer failure pattern.
+- Preserve Shopee `retcode` and message in the EDI call log.
+- Do not finalize retry/non-retry mapping in this phase.
+- Use existing transport failure handling for timeout/network errors only.
 
 - [ ] **Step 5: Add 5.1 and 5.5 Vendor-to-WES basic handlers**
 
@@ -1002,34 +1003,33 @@ cd C:\work\gitlab\shopee\wes-loghub
 .\gradlew :wms-api:compileGroovy :wms-wave:compileGroovy --no-problems-report
 ```
 
-### Task 10: Error Code and Response Contract
+### Task 10: Error Code and Response Contract Placeholder
 
 **Files:**
 - Modify: `ShopeeInboundApiHandler.groovy`
 - Modify: `ShopeeOutboundShipmentMappingService.groovy`
 
-- [ ] **Step 1: Normalize WES response**
+- [ ] **Step 1: Keep retcode mapping as a placeholder**
 
-WES standard `ResponseMessage` is acceptable inside current sync API. If raw Shopee response shape is required later, add one adapter at the boundary only:
+WES standard `ResponseMessage` is acceptable inside current sync API. Final mapping from WES errors to Shopee protocol `retcode` is not decided yet and must not be implemented in this phase.
+
+Boundary adapter behavior for now:
 
 ```groovy
 [
-    retcode: rsp.hasError() ? mappedCode : 0,
-    message: rsp.hasError() ? translatedText : 'success',
+    retcode: rsp.hasError() ? -1 : 0,
+    message: rsp.hasError() ? sanitize(rsp.message) : 'success',
     data: rsp.data ?: [:]
 ]
 ```
 
-Do not change `ResponseMessage` globally.
+Keep original WES error code/message in logs for later retcode mapping. Do not change `ResponseMessage` globally.
 
-- [ ] **Step 2: Map retry behavior**
+- [ ] **Step 2: Defer retry mapping**
 
-Use the protocol:
+Do not create a retry table or classify business `retcode` values yet.
 
-- Parameter/business errors -> no auto retry.
-- System, DB, timeout, upstream unavailable -> auto retry.
-
-Represent this either as mapped retcode or process-history reason. Do not invent a new retry table unless current sync-fail infrastructure cannot express it.
+Only transport-level failures such as timeout, connection refused, and upstream unavailable use existing retry behavior. Business retcode retry rules stay pending until the final error-code mapping is confirmed.
 
 ### Task 11: Verification and Documentation