api更新

README.md

@@ -250,7 +250,9 @@ Validation, transactions, rollback and synchronization are separate concerns.
 
 ## Synchronization
 
-Structive provides:
+Synchronization is a topology layer, not access control. It defines which intrinsically mutable properties share a managed consistency domain. Stored read-only properties are removed before lock slots are created, so metadata directly reduces runtime synchronization cost.
+
+Structive provides three defaults:
 
 ```cpp
 sync_all_independent
@@ -258,7 +260,7 @@ sync_all_shared
 sync_all_unsynchronized
 ```
 
-and per-property/group rules:
+and typed or runtime-key overrides/groups:
 
 ```cpp
 synchronization(
@@ -267,21 +269,23 @@ synchronization(
 )
 ```
 
-Only properties that require synchronization contribute lock slots. Stored read-only properties are removed from the resolved lock topology even if a broad default rule would otherwise include them.
+The several entry forms are intentional: compile-time member rules serve typed C++ code, runtime-key plans serve adapters, per-instance overrides serve exceptional objects, and guards express temporary multi-property consistency. They all resolve to the same compact lock-slot model.
 
-Multi-property guards deduplicate lock slots and acquire them in stable order:
+Multi-property guards deduplicate lock domains and acquire them in stable slot order:
 
 ```cpp
 auto guard = device.lock_unique<&Device::min_speed, &Device::max_speed>();
 auto old_min = guard.get<&Device::min_speed>();
-guard.set<&Device::min_speed>(20);
+auto old_max = guard.get<"maximum_speed">();
+guard.set<"minimum_speed">(20);
+guard.set<&Device::max_speed>(120);
 ```
 
-A typed unique guard can only be requested for intrinsically writable properties.
+Typed guard capability is constrained at compile time. Runtime-key guards validate keys and capability at runtime. See [Core Guide: Synchronization](docs/CORE_GUIDE.md#14-synchronization-plans) and `core/tests/synchronization_test.cpp` for topology, validation, blocking and lock-order coverage.
 
 ## Runtime access
 
-`Property_Object_Base` exposes only intrinsic dynamic access:
+`Property_Object_Base` is deliberately a low-level type-erased adapter boundary for code that discovers keys only at runtime:
 
 ```cpp
 Property_Object_Base& erased = device;
@@ -292,21 +296,13 @@ auto count = erased.runtime_property_count();
 Runtime operations are key based:
 
 ```text
-runtime_read(key, ...)
+runtime_read(key, context, callback)
 runtime_write(key, type_info, value)
 ```
 
-They return:
+They return `ok`, `unknown_property`, `not_readable`, `not_writable` or `type_mismatch`. Runtime write requires an exact type match and performs no implicit conversion. The read callback receives a borrowed pointer that is valid only during the callback; synchronized writable state remains read-locked while the callback executes. Stored read-only properties retain the same zero-lock fast path as typed reads.
 
-```text
-ok
-unknown_property
-not_readable
-not_writable
-type_mismatch
-```
-
-There is no runtime access mode. An external adapter decides whether it should call `runtime_read` or `runtime_write` for a given property.
+Core intentionally does not impose `variant`, `any`, conversion registries or serialization ownership on this boundary. Higher-level adapters may wrap it. There is no runtime access mode or access-control policy: an external system decides what it exposes, while Structive reports only intrinsic property capability. See [Core Guide: Runtime access](docs/CORE_GUIDE.md#22-runtime-type-erased-access) and `core/tests/runtime_api_test.cpp`.
 
 ## Current Core metadata