PR: Harden Legacy Module Resolution for Complex IDs & Improve Dev Diagnostics

[DJJones66]

PR: Harden Legacy Module Resolution for Complex IDs & Improve Dev Diagnostics

Summary

This PR makes the unified dynamic page renderer resilient to deeply composed module IDs and adds clearer dev-mode diagnostics. We correctly resolve modules when IDs follow patterns like
ServiceExample_Theme_userId_ServiceExample_Theme_actualModuleId_timestamp, and we emit structured logs that explain how a module was resolved (or why it wasn’t).
The result is fewer “module not found” cases, stable layout extraction, and faster debugging—with no API or schema changes.

Closes [#30](#30).

---

Problem / Motivation

• Complex module IDs: The previous logic assumed a simple Plugin_module_timestamp shape and failed on richer IDs produced by federated/legacy paths.
• Unclear failures: When resolution failed, devs had little insight into which parts were tried or which modules were available from the plugin.
• Layout instability: Downstream consumers (breakpoints/legacy props) extracted the wrong segment, leading to mismatches and missing components.

---

What’s Changed

1) Frontend – Legacy Module Adapter

File: frontend/src/features/unified-dynamic-page-renderer/adapters/LegacyModuleAdapter.tsx

• Primary extractor updated: Use the 6th segment (parts[5]) as actualModuleId for complex IDs:

  ServiceExample_Theme_userId_ServiceExample_Theme_actualModuleId_timestamp
  

  (Targets Theme modules like ThemeDisplay / ThemeController.)

• New combined-ID fallback: Try plugin_module form (e.g., ServiceExample_Theme) and relaxed matches:

  • m.id === combined, or m.id.endsWith(parts[2]), or m.name === parts[2].

• Final name-based fallback: Match against name / displayName (and last-resort id.includes) using the module name segment (parts[2]).

• Richer dev diagnostics (NODE_ENV === 'development' only):

  • ✅ On success: log original ID, split parts, extracted actualModuleId, and resolved module { id, name, displayName, hasComponent }.
  • ❌ On failure: log inputs plus a compact inventory of available modules { id, name, displayName }.

• Keeps original simple-pattern fallback (baseModuleId = moduleId.replace(/-\d+$/, '')) for backward compatibility.

---

2) Frontend – Layout Engine Alignment

File: frontend/src/features/unified-dynamic-page-renderer/components/LayoutEngine.tsx

• Consistent extraction: Aligns with adapter logic by using the 6th segment (parts[5]) when deriving a “simple” module ID from complex IDs for:

  • Breakpoint/layout keying
  • Legacy _legacy.moduleId prop plumbing

• Updated inline docs to reflect the canonical pattern and example.

---

User-Visible Behavior

• Legacy/complex module instances (e.g., Theme components) render reliably instead of failing to resolve.
• No changes to external API contracts, schemas, or user-facing strings—only resolution logic and dev-only console output.

---

Backward Compatibility

• ✅ No schema changes.
• ✅ No API contract changes.
• ✅ Original simple extraction and fallbacks remain; we’ve only added smarter paths and better diagnostics.

---

Risks & Mitigations

• Unexpected ID shapes → guarded by parts.length >= N checks and multi-step fallbacks (combined ID, name/displayName, simple pattern strip).
• Over-matching → strict equals first, then endsWith, and only finally includes as a last resort (dev visibility via logs).

---

TL;DR: We now correctly extract the real module ID from deeply composed IDs, try smart fallbacks, and print rich dev logs. Legacy/simple IDs still work; complex paths now do too.