<!-- ephemeral -->

Please help me complete the creation (Create) service business code for the `System Platform` object.

To ensure absolute correctness of the API, please refer to and strictly imitate the following **real creation code example for `System Platform`**.

### Standard Creation Example (Reference)
Please carefully observe the initialization of the object, the `update_xxx()` property setting methods, and the strictly required `.audit_as()` and `.save()` cascade in the example code.

```rust
use crm_erp_service_core::teaql_core::Entity;
use crm_erp_service_core::{Q, Platform, TeaqlRuntime, AuditedSave};

pub async fn create_example(
    context: &impl TeaqlRuntime,
) -> Result<Platform, Box<dyn std::error::Error>> {
    // 1. Initialize the new entity
    let mut new_entity = Q::platforms()
        .comment("what: Initialize a new entity instance")
        .purpose("why: Create a new entity instance")
        .new_entity(context);

    // 2. Set property values (replace dummy data with actual inputs)
    // new_entity.update_name(/* input data */);
    // new_entity.update_create_time(/* input data */);
    // new_entity.update_last_update_time(/* input data */);


    // 3. CRITICAL: Security audit constraints must be attached before calling save()!
    let persisted = new_entity
        .audit_as("Why this create operation was executed (audit record)")
        .save(context).await?;

    Ok(persisted)
}
```

### Your Task
Please completely imitate the framework, imports, and syntax features of the above code to implement the real creation logic for `System Platform` based on my specific business needs. Please output the Rust source code directly.

**CRITICAL**: We have already generated the correct plural/singular form for the `Q::` methods in the example above (e.g. `Q::platforms_minimal()`). Do NOT try to guess or invent a plural form yourself. You MUST copy the EXACT spelling of the `Q::` method from the example.


---

## TeaQL seven-language assist contract

Apply the verified Rust semantic ceiling while using only the exact RUST generated and
runtime APIs. Discover APIs through the generated application AGENTS.md and progressive
model-aware Assist. Do not inspect generated domain-library source.

- Do not create plurals by appending `s` or `es`; use the centralized generated plural.
- Human and non-human entities use different generated predicate vocabularies. Preserve
  forms such as “who are active” and “whose email is”; never infer them from English.
- Configure filters, projection, paging, and other query options before `purpose(...)`.
  Comment may appear anywhere in the chain. Purpose enters the executable stage; execution
  requires both values, but comment does not have to immediately precede purpose.
- Every execute/list/stream and every save accepts exactly one context argument:
  `UserContext`. Name that argument `context`, never `runtime`; data services and global
  policy are injected when the context is built. Reserve `runtime` for process-level
  runtime ownership, provider/pool setup, and module assembly.
- Tenant, merchant, identity, permissions, request policy, purpose policy, hard limit,
  and continuous-page cursor policy come only from trusted context, never dynamic JSON or TFP.
- If the required operation is absent after current entity/action and required field
  Assist, stop that path and report MISSING_ASSIST. Do not guess an API or search the
  generated library as a fallback.
- Create each application-owned source file once. After its first compile attempt,
  repair only the smallest block identified by the exact compiler or test diagnostic.
  Preserve unrelated code; do not rewrite the complete file as an error-recovery loop.
- Before a repair that would replace more than 25% of an existing application file,
  stop and report LARGE_REWRITE_REQUEST with the file, exact diagnostic, reason, and
  estimated scope. Initial creation and model-driven regeneration are not repairs.

Capability: `create`.

- Validate and allow-list writable business fields; never mass-assign dynamic JSON.
- Create through the generated request/entity API, attach a non-empty audit reason,
  save with the same UserContext, and return the runtime's native save result.
- Add a negative test proving a missing audit reason cannot write.