Repository navigation
SchemaNodeViewer for Schema Editing (DEFERRED - Backend Complete) #195
Description
Activity
- changed the title
[-]Implement SchemaNodeViewer for Schema Editing[/-][+]SchemaNodeViewer for Schema Editing (DEFERRED - Backend Complete)[/+]on Nov 2, 2025 - added 4 commits that reference this issue
on Nov 2, 2025 - added 8 commits that reference this issue
on Feb 4, 2026 Triage (2026-09-11): still correctly deferred
Checked all three stated deferral conditions. None have changed in a way that argues for building this now.
1. Is #106 "complete and stable"?
#106 itself closed 2025-11-03 (PR #377), but "schema management" as a system is not frozen — it's had substantial, structural churn right up through this month:
- Split SchemaField into name/friendly_name/description #2105 split
SchemaFieldintoname/friendly_name/description - Person schema: replace name with first_name and last_name #2508 changed the
personschema itself (name→first_name/last_name) - Replace task's free-text assignee field with a person->task relationship #2507 replaced task's free-text assignee with a
person→taskrelationship - Enforce Core/System field protection on update_schema removes and renames, validate rename grammar before persisting #2304 (closes update_schema deletes Core/System-protected schema fields with no protection-level check (guard bypass) #2194/rename_schema_field rekeys Core/System-protected fields with no protection check (same guard bypass) #2195/update_schema rename_fields persists the rename BEFORE field-name grammar validation runs — invalid field names get committed to schema and all node data, then the caller is told the update failed #2208/update_schema never enforces field protection levels: Core-protected fields (e.g. task.status) can be removed from or renamed on core schemas via one agent tool call, and the change is irreversible through the API #2213) added Core/System field-protection enforcement on
update_schemaremoves/renames - Validate object-typed fields structurally in schema validation #2458 added structural validation for object-typed fields
- Let an edge field declare a closed enum value set (closes #2387) #2427/Require reverseName and reverseCardinality so a relationship edge is named from both ends (closes #2433) #2437 added closed enum value sets + required reverse-relationship metadata on edge fields
- Filter system-protected fields out of table columns (closes #2376) #2404/Filter system-protected fields out of relationship columns (closes #2408) #2411 (this week) started filtering system-protected fields out of table/relationship columns
If anything, this cuts the other way: the schema model is still actively evolving (field shape, protection semantics, validation rules). Building a visual editor on top of a moving target now would mean either building against a schema shape likely to change again, or becoming a drag on further schema evolution. "Stable" hasn't arrived yet.
2. Any actual request for a visual schema editor since filing?
Searched issue/PR titles+bodies repo-wide for "schema editor," "visual schema," and "SchemaNodeViewer" — no hits besides #195 itself. What did turn up is read/browse-oriented UI (Schema Types sidenav + QueryNodeViewer integration in #960, relationship viewer in #1918/#2446, generic entity rendering polish in #449) and instance-level property forms (#2027/#2031, #2141's
TypedFormShell/SchemaFieldLeaf) — none of that is a schema-definition editor (add/remove fields, change protection levels, extend enums visually). No evidence of user/team demand for that specific capability.Also notable: #2152/#2181 (closed 2026-08-20) went the other direction — removing entity-type slash commands (
/person,/ai-chat, user-defined types) to enforce a "primitives + task" rule, routing entity-type creation through sidenav → type view → create-instance instead. Product direction here has been toward narrowing UI surface around entity types, not expanding it — a soft signal against prioritizing a bigger schema-editing UI feature right now.3. Does the MCP reintroduction (#2512, merged) change the calculus?
No — orthogonal, as the issue itself anticipated. #2512 adds trust-boundary controls around
nodespace mcp, a passthrough CLI-over-JSON-RPC tool for bash-less surfaces (Claude Desktop's Chat tab, claude.ai) per ADR-035/ADR-038. It's an access-mechanism change, not a schema-manipulation-capability change — schema CRUD already happens vianodespace schemaCLI subcommands andcreate_schema/update_schemaagent tools regardless of whether the caller reaches the CLI directly (shell-capable harnesses) or via the new MCP passthrough (bash-less harnesses). Those tools are demonstrably actively used and maintained (#2435 addedschema delete, #2164 addedfriendly_nameto tool schemas, #2304 hardened protection enforcement) — "AI agents provide sufficient schema manipulation capabilities" still holds and is exercised in practice, independent of MCP's transport.Conclusion: both stated conditions ("users request a visual schema editor" / "#106 phases complete and stable") remain unmet. Leaving this open, deferred, as-is — no re-scope, no implementation. Next re-check should look for the same two signals: an actual user/team ask for visual schema editing, and the schema model settling down (no structural changes for a stretch).
- Split SchemaField into name/friendly_name/description #2105 split
Status: DEFERRED
Backend schema management implemented via #106. UI can be implemented when needed.
AI agents and MCP provide sufficient schema manipulation capabilities for now. This UI is a nice-to-have for visual schema editing.
When to implement: When users request visual schema editor or when #106 phases are complete and stable.