Object-valued properties are silently dropped on non-task types #2430

What happens

Setting an object-valued property on any type other than task stores it where every read path's flattener will never look, so the field vanishes from output. Not mangled, not null — absent, with no error.

nodespace node create --type venue --property address='{"city":"Berlin"}'
nodespace node get --json <id>   # address is gone

references/cli.md advertises object values as supported input ("Values are parsed as JSON when possible (numbers, booleans, arrays, objects)"), so this is a documented input shape that silently loses data.

Mechanism

create_node (packages/core/src/services/node_service/crud.rs:99) resolves schema fields only for task; every other type normalizes with schema_fields: None.

With an empty schema_field_names, normalize_flat_properties_to_namespace (crud.rs:1704) classifies any object value as a namespace rather than a field:

if value.is_object() && !schema_field_names.contains(key.as_str()) {
    // treated as a (dormant) namespace and hoisted out of the type key

The property lands beside properties[node_type] instead of inside it. flatten_namespaced_properties then reads only the type's own namespace, so the field is dropped.

The codebase already documents this hazard verbatim at packages/agent/src/skill_pipeline.rs:482:

the normalizer misclassifies parameter_schema (an object) as a dormant namespace, hoisting it out of the "tool" key so flatten_properties_for_api later silently drops it.

Seed templates work around it by pre-namespacing. A user typing --property has no such escape hatch.

Scope

No built-in type loses data today: tool pre-namespaces, and schema's fields is an array (which survives the !is_object() filter). The exposure is latent, firing on any user-defined object field.

Why this needs a design decision, not a one-line fix

The obvious fix — resolve schema fields for all types — is explicitly rejected by a measured performance constraint at crud.rs:91:

Only fetch schema from DB for types with meaningful schema fields. Currently only "task" has schema-defined fields; text, date, etc. have no fields. This avoids a ~760ms database lookup for every node creation.

That comment's premise is now stale (user-defined schemas have fields too), but simply removing the gate would reintroduce a ~760ms regression on every node create. A real fix needs one of:

• a schema cache, so the lookup isn't per-create;
• narrowing the lookup to creates that actually carry an object-valued property;
• or distinguishing field-vs-namespace without a schema at all (e.g. an explicit namespace marker at rest).

Each needs fresh measurement against the 760ms claim, which predates the current store.

Acceptance criteria

• An object-valued property set on a non-task type round-trips through node get, query, and relationship get
• No per-create schema lookup regression — measure against the ~760ms figure in crud.rs:91 and record the result (that number predates the current store; re-measure rather than trusting it)
• skill_pipeline.rs's pre-namespacing workaround is removed if the fix makes it unnecessary, or its comment updated to point here if not
• The cli.md caveat added by the flat-CLI-output change is removed once object values round-trip
• Covers a user-defined type with an object field end-to-end, not just a unit test of the normalizer

Context

Found during code review of the PR that made CLI read output flat. That change is what makes this user-visible: the nesting used to be observable in raw output, so a dropped field was at least inspectable. Now output is authoritative and the loss is invisible, which is why that PR added an explicit docs caveat rather than claiming completeness.