Remove deprecated schema extensions and related functionality

[jfrench9]

Summary

Removes five deprecated schema extension modules (roboepm, robofo, robohrm, roboreport, roboscm) and cleans up all related functionality across the codebase, eliminating approximately 2,050 lines of unused code.

Key Accomplishments

• Deleted 5 extension schema modules under robosystems/schemas/extensions/ that were no longer in use:

  • roboepm.py — Enterprise Performance Management schema
  • robofo.py — Finance Operations schema
  • robohrm.py — Human Resource Management schema
  • roboreport.py — Reporting schema
  • roboscm.py — Supply Chain Management schema

• Cleaned up the schema loading pipeline by removing extension-related logic from loader.py and runtime/manager.py, simplifying how schemas are discovered and managed at runtime.

• Simplified API and data models by removing extension-related fields and handling from entity_graph.py and the graphs router (routers/graphs/main.py).

• Updated schemas/base.py to remove extension surface area that is no longer needed.

• Updated db/extensions.py to reflect the removal of the deprecated extension references.

• Updated documentation in schemas/README.md to reflect the current state of the schema system without the removed extensions.

• Pruned related test code from test_entity_graph_models.py, test_schema_loader.py, and test_schema_manager.py, removing tests that validated the now-deleted extension functionality.

Breaking Changes

• Schema extension modules removed: Any downstream consumers or integrations that directly referenced the roboepm, robofo, robohrm, roboreport, or roboscm extension schemas will break. Ensure no active features depend on these extensions before merging.
• API surface changes: Fields or behaviors in the entity graph API related to schema extensions have been removed. Clients relying on extension-specific data in graph responses may be affected.
• Schema loader/manager behavior: The loader and runtime manager no longer support dynamically loading extension schemas. Any external tooling that relied on this mechanism will need to be updated.

Testing Notes

• Existing tests have been updated to remove assertions and fixtures tied to the deleted extensions.
• Verify that the remaining schema loading and runtime management tests pass without regressions.
• Confirm that entity graph API endpoints function correctly without extension-related fields.
• Integration and end-to-end tests should be run to ensure no hidden dependencies on the removed extensions exist.

Infrastructure Considerations

• Deployment pipelines should be validated to ensure they do not reference or depend on the removed extension schema files.
• If any configuration or environment-level settings reference these extensions (e.g., feature flags, schema registries), they should be cleaned up in coordination with this change.
• Database migrations or data cleanup may be needed if extension-related data was persisted and is now orphaned.

---

🤖 Generated with Claude Code

Branch Info:

• Source: refactor/remove-unused-extensions-surface
• Target: main
• Type: refactor

Co-Authored-By: Claude noreply@anthropic.com

[jfrench9]

@claude please review this PR

[claude]

Claude finished @jfrench9's task in 1m 58s —— View job

---

PR Review: Remove deprecated schema extensions

• Read changed files and git diff
• Check for remaining references to deleted modules
• Review schema loader/manager changes
• Review API model changes
• Review test changes
• Post comprehensive review feedback

---

Overall: Clean, well-scoped removal of dead code. No dangling references found. A few minor notes below.

---

What was verified

No lingering references: A full grep across *.py, *.md, *.yml, *.json, and *.toml found zero remaining references to roboepm, robofo, robohrm, roboreport, or roboscm. The deletions are complete.

Dynamic loader handles this correctly: loader.py's _discover_all_extensions() uses pkgutil.iter_modules to discover extensions at runtime — deleting the files is sufficient to remove them from discovery. No hardcoded lists to miss.

SchemaType enum: Correctly trimmed to BASE, ROBOLEDGER, ROBOINVESTOR, MEMORY. No consumer references to the removed enum values exist.

API validation (entity_graph.py): The available_extensions allowlist is correctly reduced to {"roboledger", "roboinvestor"}.

---

Minor observations

1. No test asserting removed extensions are now rejected

The test_unknown_extension_rejected test exercises an arbitrary unknown string ("unknown_ext"), but there's no explicit test confirming that a previously-valid extension like "roboscm" is now correctly rejected. This would document the breaking change and guard against accidental re-allowlisting:

def test_removed_extensions_now_rejected(self):
    with pytest.raises(ValidationError):
        EntityCreate(name="Test", extensions=["roboscm"])

Fix this →

2. ROBOINVESTOR SchemaType has no test

TestSchemaType in test_schema_manager.py covers BASE, ROBOLEDGER, and MEMORY — but not ROBOINVESTOR (line 20–30). Not introduced by this PR, but the test-cleanup pass was a natural opportunity to close the gap.

3. test_all_valid_extensions name is slightly stale (test_entity_graph_models.py:89)

The method is named test_all_valid_extensions but now only contains 2 extensions. The name no longer accurately conveys intent vs. the more targeted test_valid_extensions just above it. Consider renaming to test_both_valid_extensions or folding it into the one above.

4. Pre-merge data check recommended

The PR description flags: "Database migrations or data cleanup may be needed if extension-related data was persisted and is now orphaned." These five schemas were graph-schema-only (LadybugDB/Cypher) with no OLTP layer. If any live graph has these schema extensions listed in graph.schema_extensions (platform DB), the get_available_extensions endpoint will now silently return no info for those names. Worth a quick SELECT DISTINCT schema_extensions FROM graphs WHERE schema_extensions && ARRAY['roboscm','robofo','robohrm','roboepm','roboreport'] against staging/prod before merging.

---

Summary

The mechanical work here is solid — the right files were deleted, the right fields were trimmed, the loader's dynamic discovery mechanism means no hardcoded list was missed, and the documentation is updated with a clear forward-looking rationale. The minor items above are all low-risk suggestions, not blockers. Safe to merge after the data check.
|