Remove skeleton workflows, simplify deploy to single job, add initial deployment guide with Ontology workaround

Author: michaeldeongreen

.github/workflows/deploy-prod.yml

@@ -1,13 +1,14 @@
 # Orchestrator workflow for deploying Fabric items to the Prod workspace.
 #
-# Job 1 deploys all supported items (including Ontology and DataAgent) via
-# fabric-cicd. Jobs 2-3 are skeletons reserved for future item types that
-# lack fabric-cicd support and require Deployment Pipeline promotion.
+# Deploys all supported items via fabric-cicd. The reusable workflow handles
+# phased deployment internally (Lakehouse + Ontology first, then everything
+# else) to satisfy fabric-cicd dependency resolution.
+#
 # The `prod` GitHub Environment should have protection rules configured
 # (e.g., required reviewers, branch policy restricting to main only).
 #
-# Jobs run sequentially via `needs:`. The ETL workflow (etl-prod.yml) triggers
-# automatically via workflow_run once all 3 jobs complete successfully.
+# The ETL workflow (etl-prod.yml) triggers automatically via workflow_run
+# once deployment completes successfully.
 
 name: Deploy to Prod
 
@@ -27,19 +28,3 @@ jobs:
       environment: Prod
       item_type_in_scope: '["Lakehouse", "Ontology", "VariableLibrary", "Notebook", "SemanticModel", "Report", "DataAgent"]'
     secrets: inherit
-
-  promote-unsupported:
-    name: Promote unsupported items
-    needs: deploy-supported
-    uses: ./.github/workflows/reusable-deploy-unsupported.yml
-    with:
-      environment: Prod
-    secrets: inherit
-
-  deploy-supported-dependent:
-    name: Deploy dependent supported items
-    needs: promote-unsupported
-    uses: ./.github/workflows/reusable-deploy-supported-dependent-on-unsupported.yml
-    with:
-      environment: Prod
-    secrets: inherit

.github/workflows/etl-test.yml

@@ -2,8 +2,7 @@
 #
 # Uses workflow_run to decouple deploy and ETL as separate workflow concerns.
 # The `if` condition ensures ETL only runs when the deploy workflow succeeded —
-# if any sandwich job fails, the deploy workflow is marked as failed and this
-# workflow skips execution.
+# if the deploy workflow fails, this workflow skips execution.
 #
 # ETL_ITEM_ID is no longer needed — the notebook is resolved by name at runtime.
 

.github/workflows/reusable-deploy-supported-dependent-on-unsupported.yml

@@ -4,7 +4,7 @@
 # to publish all supported item definitions from the Git repo to the target
 # Fabric workspace, then removes any orphaned items no longer in the repo.
 #
-# Called by: deploy-test.yml, deploy-prod.yml (Job 1 of the sandwich pattern)
+# Called by: deploy-test.yml, deploy-prod.yml
 #
 # Prerequisites:
 #   - GitHub Environment secrets: AZURE_TENANT_ID, AZURE_CLIENT_ID,

.github/workflows/reusable-deploy-supported.yml

@@ -45,7 +45,7 @@ Git repo (dev branch)
 | Document | Description |
 |---|---|
 | [CI/CD Release Options](fabric-cicd-release-options.md) | Evaluates all CI/CD release options for Fabric (Deployment Pipelines, Git-based, Build-based, Hybrid) and recommends the Hybrid approach. **Start here** if you're deciding on a strategy. |
-| [Hybrid CI/CD Implementation Guide](fabric-hybrid-cicd-guide.md) | Deep dive into the implementation: workflow structure, sandwich pattern, configuration strategy, prerequisites, setup steps, and gotchas. |
+| [Hybrid CI/CD Implementation Guide](fabric-hybrid-cicd-guide.md) | Deep dive into the implementation: workflow structure, configuration strategy, prerequisites, setup steps, and gotchas. |
 | [Development Process](fabric-development-process.md) | How developers work day-to-day: branch-out workflow, environment bootstrap/reset script, and PR validation. |
 
 ---
@@ -66,7 +66,7 @@ Not all Fabric items can be managed the same way. From a lifecycle management pe
 
 > **Important:** Both supported items lists evolve as Microsoft adds capabilities. Always verify against the official documentation before assuming an item falls into a particular category.
 
-This categorization directly impacts your CI/CD strategy. The [Hybrid CI/CD Implementation Guide](fabric-hybrid-cicd-guide.md) uses the "sandwich pattern" to handle the gap between git-tracked and deployment-pipeline-only items, though currently all items in this repository are deployed via fabric-cicd.
+This categorization directly impacts your CI/CD strategy. The [Hybrid CI/CD Implementation Guide](fabric-hybrid-cicd-guide.md) describes how to handle the gap between git-tracked and deployment-pipeline-only items if your workspace includes unsupported types. Currently, all items in this repository are deployed via fabric-cicd.
 
 ### Variable Libraries: Dynamic vs Static Metadata