Namespace object-valued properties by key prefix, not value type (closes #2430)

[malibio]

Closes #2430.

Setting an object-valued property on any type but task silently lost the data — no error, no null, just absent from every read path.

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

The mechanism

normalize_flat_properties_to_namespace decided whether a property was a field of its type or a sibling namespace by looking at the value's JSON type — an object meant "namespace". Because create_node resolved schema fields only for task, every other type normalized against an empty field-name set, so any object value was hoisted out of properties[node_type]. The flattener reads only the type's own namespace, so the field vanished.

Why not just look up the schema

The issue names three candidate fixes and asks for a measurement, because the gate that blocked the obvious one cited a hard number:

This avoids a ~760ms database lookup for every node creation.

That number is stale by about four orders of magnitude. get_schema is get_node(node_type) — a single primary-key read on an indexed column. Measured against the current libsql/SQLite store, 500 iterations after warmup with 500 filler rows present:

	per call	vs. the claimed 760ms
release, schema hit	0.011 ms	~67,000x lower
release, schema miss	0.003 ms	~230,000x lower
debug, schema hit	0.019 ms	~40,000x lower
debug, schema miss	0.010 ms	~76,000x lower

So there was nothing to gate on. The measurement harness was temporary and is not part of this PR.

The approach chosen

Rather than pay even that lookup to resolve an ambiguity, this removes the ambiguity. Classification now keys off the property name, not its value:

• _-prefixed keys (_seed, _schema_version) are internal bookkeeping and stay at the top level, at a fixed type-independent path;
• every other key is a field of this type and is namespaced whatever its value — object-valued fields included.

That prefix was already reserved on the read side — flatten_namespaced_properties drops _-prefixed keys from every read surface — so this makes the write path agree with the read path rather than diverge from it. It needs no schema, so normalization is now schema-free everywhere and correct for user-defined types by construction.

With the gate's premise gone, schema defaults and validation now run for every type that declares a schema, so user-defined types get them too (previously task-only).

Knock-on changes

• Removed the tool seed pre-namespacing workaround in skill_pipeline.rs, which existed only to dodge this misclassification. Its properties are now plain flat fields like every other seed template; the stored shape is unchanged.
• Declared idle and processing on the ai-chat status enum. Two orthogonal state machines share that key — the daemon's turn state and the PTY session lifecycle — but the schema declared only the latter. Validating non-task types on update surfaced the gap. The frontend's AiChatStatus already lists all four values, so this brings the backend into line with a contract that was already written down.
• Removed the cli.md caveat that told callers to avoid object properties.

Tests

New packages/core/tests/object_valued_property_roundtrip_test.rs covers a user-defined venue type with an address object field, end to end through each read surface that flattens independently:

• get_node, query_nodes, and get_related_nodes (all three, since they reach the flattener by different routes)
• an update round-trip, including that an untouched scalar sibling survives the deep merge
• _-prefixed keys staying out of the type namespace

All five were confirmed to fail against the old value-type classification and pass with the fix, so they genuinely pin the bug rather than just describing current behavior.

Frontend baseline 233 files / 4900 tests — unchanged after the fix. Full test:all green (58 result groups, 0 failures); quality:fix clean including clippy -D warnings.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KwcVcLdvBUjSkUFmtFNiTY

[malibio]

Review addressed

🟡 BLOCKING — _-prefixed schema field names silently swallowed — fixed

Confirmed the finding: create_schema accepted _internal_id, the write stored it top-level, and every read dropped it — the same silent-loss class this PR closes, relocated rather than closed.

Chose hard reject over warn. The distinction that decides it: a name shadowing a reserved core property warns because the field still works and only may be shadowed later. A _-prefixed field is unreadable by construction — flatten_namespaced_properties drops those keys from every read surface unconditionally — so accepting it means accepting a write guaranteed never to be readable. That is the defect itself, not a style question.

Placed in validate_schema_field_name (behaviors/mod.rs) rather than beside warn_reserved_property_names, because it is the single well-formedness gate that both create_schema and update_schema's rename path already route through, and it recurses into nested/item_fields for free. The rename route turned out to be the higher-stakes one: its existing comment notes the destination name must be checked before Phase 1, since a rename migrates every instance's property data as it executes — so a rename to _foo would move real stored values into an unreadable key before anything caught it.

Scoped to the stored key, which is the name verbatim. Only a leading _ on the whole name is fatal: custom:_internal stores under a key beginning c, survives the flattener, and stays legal. Verified empirically, not by inspection, and pinned by a test so the gate cannot later over-reach into it.

Three tests added, asserting the failure mode:

• schema_cannot_declare_an_underscore_prefixed_field — also asserts no half-created schema node is left behind
• a_field_cannot_be_renamed_to_an_underscore_prefixed_name — asserts instance data was not migrated, i.e. the rejection landed pre-migration
• a_namespaced_field_may_contain_an_underscore_after_the_prefix — the over-reach guard

Both gate tests were confirmed to fail with the check disabled and pass with it. Also verified nothing existing declares such a field, so the gate breaks no current schema or seed.

Also added (cheap, from the non-blocking list)

object_property_survives_a_bulk_update — bulk_update reaches the normalizer through a different call site than update_node, so it could drift. Includes an empty {} value, the one shape whose two readings ("object-valued field" vs "empty namespace") were genuinely ambiguous under the old value-type classification.

Skipped, per instruction — will be filed as follow-ups

• ai-chat enum permits nonsense (archived + processing). Agreed; splitting into two properties is the correct end state and is out of scope here.
• type: "object" declared but never validated — pre-existing, unrelated to this change.
• markdown import / arrays-of-objects round-trips — left to the follow-up. Import is also the lower-risk path: import_nodes never calls validate_node_against_schema, so it is untouched by this PR's validation widening.

Verification

Full test:all green (61 result groups, exit 0); round-trip suite now 9/9; quality:fix clean including clippy -D warnings.

Thanks for the review — the blocking finding was a real hole, and catching that the fix's own mechanism opened a new door to the same failure was the right call.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KwcVcLdvBUjSkUFmtFNiTY