feat(node-type-registry): add source_field/target_field to RelationSpatial BlueprintRelation arm (v0.15.0)

[pyramation]

Summary

Adds source_field and target_field (required, string) to the RelationSpatial arm of the generated BlueprintRelation union so blueprint authors can write a RelationSpatial entry without casting through a local interface.

Why: RelationSpatial is the only relation node that references existing columns (rather than creating FK/junction columns). Its parameter_schema is in ID-space (source_field_id, target_field_id as UUIDs), but blueprint JSON is in name-space (source_field, target_field as strings, resolved server-side by resolve_blueprint_field). Those name-space fields had no equivalent in RelationSpatialParams, so the generated BlueprintRelation arm was missing them — forcing downstream consumers (e.g. agentic-db) to define a local SpatialRelationEntry interface and as unknown as BlueprintRelation[] cast.

Changes:

• codegen/generate-types.ts — buildRelationTypes now appends source_field / target_field required props to the union arm when nt.name === 'RelationSpatial'.
• blueprint-types.generated.ts — regenerated output with the two new required fields on the RelationSpatial arm.
• package.json — version bump 0.14.0 → 0.15.0.

Follow-up (separate PR, agentic-db): bump this dep and drop the local SpatialRelationEntry cast.

Review & Testing Checklist for Human

• Confirm the minor version bump (0.14.0 → 0.15.0) is appropriate. Technically this adds two required fields to the RelationSpatial arm — any existing blueprint that constructed a RelationSpatial entry without source_field / target_field will now fail type-check. In practice those fields were already required at runtime (the server-side dispatcher reads them), so this just surfaces an existing requirement. Confirm no other consumer constructs RelationSpatial entries that would regress.
• Cosmetic: the regenerated blueprint-types.generated.ts renders the JSDoc comments inline with the property (/** ... */source_field: string;) rather than on the line above. This is valid TS and matches what @babel/generator emits for leading comments on TSTypeElements inside a type literal, but if you'd prefer the comments above the props I can switch to plain block comments (/* ... */) like the requiredProp comments in BlueprintFullTextSearch.
• Sanity-check the special-case approach (if (nt.name === 'RelationSpatial')) vs. a more extensible mechanism (e.g. a blueprint_json_extra_fields key on NodeTypeDefinition). I went with the special-case because RelationSpatial is the only node today that needs name-space-only blueprint fields; happy to generalize if you'd rather.

Notes

• Verified by running pnpm run generate:types locally; output matches the committed blueprint-types.generated.ts.
• No tests in graphql/node-type-registry/ — relying on CI + downstream consumers (agentic-db follow-up PR) for validation.

Link to Devin session: https://app.devin.ai/sessions/c5eeee65a3c546c4ac6753bb05fa03e0
Requested by: @pyramation

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​types/​babel__generator@​7.27.0

View full report