$## Context\n\nNew repositories created from Template-PSModule require repeated manual setup before documentation publishing is fully operational.\n\n## Request\n\nAfter repository creation, GitHub Pages must be configured to deploy from GitHub Actions, HTTPS enforcement must be enabled, and main must be removed from branch restrictions in the github-pages environment protection rules.\nThe current process is manual and repeated across repositories, which increases setup time and introduces configuration drift risk.\n\n### Desired capability\n\nA standardized and repeatable automation approach is needed to apply this baseline configuration consistently for every new repository created from the template.\n\n### Acceptance criteria\n\n- A documented comparison exists for all candidate approaches\n- The comparison includes security, operational complexity, maintenance cost, and failure recovery\n- A recommended approach is selected with clear rationale\n- Required permissions and credential model are explicitly defined\n- Rollout and fallback strategy is documented\n\n---\n\n## Technical decisions\n\nScope: This issue is an evaluation/planning issue only; no implementation changes are in scope.\n\nRequired configuration actions:\n- Configure Pages build/deploy source to GitHub Actions using the GitHub Pages API\n- Enable HTTPS enforcement (https_enforced) via the Pages API\n- Update environment protection settings for github-pages via the Deployments and environments API\n\nEvaluation criteria:\nUse a weighted comparison with the following dimensions:\n\n| Criterion | Description |\n|---|---|\n| Security posture | Least privilege, token scope, secret handling, auditability |\n| Time-to-value | Setup effort and speed to first successful rollout |\n| Reliability | Idempotency, retry behavior, error handling, drift correction |\n| Operability | Monitoring, alerting, support burden, debuggability |\n| Scalability | Works across many repositories and repeated template usage |\n| Governance fit | Alignment with org-level controls and compliance expectations |\n\nApproaches to evaluate:\n\n1. In-repo bootstrap workflow with GitHub App token\n Run a setup workflow in the new repository (or from org automation) using a GitHub App installation token stored/managed at the organization level.\n References: Authenticating as a GitHub App installation, GitHub Actions workflow syntax\n\n2. Event-driven GitHub App + webhook processor\n A GitHub App subscribes to repository creation/template events and performs configuration in an external execution environment.\n References: Webhook events and payloads, Building GitHub Apps\n\n3. Infrastructure as code reconciliation (Terraform)\n Manage target repositories declaratively and reconcile settings after creation.\n References: Terraform GitHub Provider\n\n4. Organization-level reusable workflow orchestration\n Trigger a centralized reusable workflow after template creation to apply settings consistently from one maintained workflow.\n References: Reusable workflows\n\n5. Policy-first controls where possible\n Use org-level controls (for settings that support it) and minimize per-repo mutation automation to only unsupported settings.\n References: Organization policies and repository management\n\nBackward compatibility / rollout risk:\nNo runtime product impact; risk is operational misconfiguration during repository bootstrap. Pilot rollout is required.\n\n---\n\n## Implementation plan\n\n### Discovery and constraints\n\n- [ ] Confirm exact API operations and permissions needed for Pages and environment protection updates\n- [ ] Confirm which settings can be enforced centrally vs. require per-repo mutation\n- [ ] Define success/failure signals for automated setup\n\n### Option analysis\n\n- [ ] Build a decision matrix scoring each approach against agreed criteria\n- [ ] Document required trust boundaries and credential flows for each approach\n- [ ] Document operational model (triggering, retries, drift detection, observability)\n\n### Recommendation\n\n- [ ] Select a recommended approach with rationale and trade-offs\n- [ ] Define phased rollout (pilot repositories, expansion criteria, fallback)\n- [ ] Define follow-up implementation issues for selected approach
$## Context\n\nNew repositories created from
Template-PSModulerequire repeated manual setup before documentation publishing is fully operational.\n\n## Request\n\nAfter repository creation, GitHub Pages must be configured to deploy from GitHub Actions, HTTPS enforcement must be enabled, andmainmust be removed from branch restrictions in thegithub-pagesenvironment protection rules.\nThe current process is manual and repeated across repositories, which increases setup time and introduces configuration drift risk.\n\n### Desired capability\n\nA standardized and repeatable automation approach is needed to apply this baseline configuration consistently for every new repository created from the template.\n\n### Acceptance criteria\n\n- A documented comparison exists for all candidate approaches\n- The comparison includes security, operational complexity, maintenance cost, and failure recovery\n- A recommended approach is selected with clear rationale\n- Required permissions and credential model are explicitly defined\n- Rollout and fallback strategy is documented\n\n---\n\n## Technical decisions\n\nScope: This issue is an evaluation/planning issue only; no implementation changes are in scope.\n\nRequired configuration actions:\n- Configure Pages build/deploy source to GitHub Actions using the GitHub Pages API\n- Enable HTTPS enforcement (https_enforced) via the Pages API\n- Update environment protection settings forgithub-pagesvia the Deployments and environments API\n\nEvaluation criteria:\nUse a weighted comparison with the following dimensions:\n\n| Criterion | Description |\n|---|---|\n| Security posture | Least privilege, token scope, secret handling, auditability |\n| Time-to-value | Setup effort and speed to first successful rollout |\n| Reliability | Idempotency, retry behavior, error handling, drift correction |\n| Operability | Monitoring, alerting, support burden, debuggability |\n| Scalability | Works across many repositories and repeated template usage |\n| Governance fit | Alignment with org-level controls and compliance expectations |\n\nApproaches to evaluate:\n\n1. In-repo bootstrap workflow with GitHub App token\n Run a setup workflow in the new repository (or from org automation) using a GitHub App installation token stored/managed at the organization level.\n References: Authenticating as a GitHub App installation, GitHub Actions workflow syntax\n\n2. Event-driven GitHub App + webhook processor\n A GitHub App subscribes to repository creation/template events and performs configuration in an external execution environment.\n References: Webhook events and payloads, Building GitHub Apps\n\n3. Infrastructure as code reconciliation (Terraform)\n Manage target repositories declaratively and reconcile settings after creation.\n References: Terraform GitHub Provider\n\n4. Organization-level reusable workflow orchestration\n Trigger a centralized reusable workflow after template creation to apply settings consistently from one maintained workflow.\n References: Reusable workflows\n\n5. Policy-first controls where possible\n Use org-level controls (for settings that support it) and minimize per-repo mutation automation to only unsupported settings.\n References: Organization policies and repository management\n\nBackward compatibility / rollout risk:\nNo runtime product impact; risk is operational misconfiguration during repository bootstrap. Pilot rollout is required.\n\n---\n\n## Implementation plan\n\n### Discovery and constraints\n\n- [ ] Confirm exact API operations and permissions needed for Pages and environment protection updates\n- [ ] Confirm which settings can be enforced centrally vs. require per-repo mutation\n- [ ] Define success/failure signals for automated setup\n\n### Option analysis\n\n- [ ] Build a decision matrix scoring each approach against agreed criteria\n- [ ] Document required trust boundaries and credential flows for each approach\n- [ ] Document operational model (triggering, retries, drift detection, observability)\n\n### Recommendation\n\n- [ ] Select a recommended approach with rationale and trade-offs\n- [ ] Define phased rollout (pilot repositories, expansion criteria, fallback)\n- [ ] Define follow-up implementation issues for selected approach