Symptom on the GCP→OCI PostgreSQL deck: the OCI PostgreSQL icon bbox rendered as empty space — labels and surrounding ADs all visible, but no icon where the postgres stencil should be. Root cause: ``_lookup_icon_ref`` returned the first hit from ``stencils.database_icons`` without checking it was cloneable. The bucket happens to ship one degraded entry — ``database`` is ``tag=sp`` with ``bbox=None`` (a label-strip leaf, not the real icon group) — so ``_clone_translated_block`` emitted a zero-size shape. The 19 viable refs for the same key in ``shape_library.entries`` were ignored because the early-return in ``database_icons`` won. Fix: extract a shared ``_is_viable_ref`` predicate (slide_path + child_index/node_path + non-empty bbox + supported tag) and apply it before returning from BOTH stencil buckets (``database_icons``, ``sample_icon_refs``). On miss, fall through to ``shape_library_entries`` where ``_select_preferred_ref`` already filtered the same way. Affects every alias that routes to a degraded stencil entry — ``postgresql`` / ``postgres`` / ``oci_postgresql`` were the obvious fallout because they all alias to ``database``. The Architecture Center reconstructions on shape-library-only slugs were unaffected. Verified by re-rendering examples/output-gcp-virginia-oci-postgres- adbs-clone/*.pptx — the OCI PostgreSQL bbox now shows the icon (teal stencil + "Database" intrinsic caption) consistently with the ADB-S and Refreshable Clone bboxes next to it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
63 KiB
63 KiB