ci: drop unused scheduled workflows (security-scan, template-sync)

docs/github-repository-settings.md

@@ -13,7 +13,7 @@ The release workflow is the only one that needs secrets. Both live under **Setti
 | `SEMANTIC_RELEASE_TOKEN` | `release.yaml` (`github_release` job) | A Personal Access Token with `repo` write so semantic-release can tag the release and push the version-bump commit back to `main`. The default `GITHUB_TOKEN` cannot push to a protected branch, which is why a PAT is required. |
 | `PYPI_API_TOKEN` | `release.yaml` (`publish` job) | PyPI API token used by `twine upload`. Scope it to the project once the package is published for the first time. |
 
-See [github-workflows.md](github-workflows.md#setting-up-secrets) for the step-by-step on creating each token. The other workflows (`test.yml`, `security-scan.yaml`, `template-sync.yaml`) run on the default `GITHUB_TOKEN` and need no secrets.
+See [github-workflows.md](github-workflows.md#setting-up-secrets) for the step-by-step on creating each token. The test and scaffold workflows (`test.yml`, `scaffold-test.yml`) run on the default `GITHUB_TOKEN` and need no secrets.
 
 ### PyPI Trusted Publisher (modern alternative)
 
@@ -51,7 +51,9 @@ The test workflow (`test.yml`) declares a job called `test` with a matrix over P
 
 If you drop a Python version from the matrix in `test.yml`, also drop it from the required checks; otherwise PRs will block forever waiting for a check that never runs. The placeholder check rides on the `3.10` leg via an `if:` guard in `test.yml`; if you change which Python version runs that step, update the guard to match.
 
-The security scan (`security-scan.yaml`) and template sync (`template-sync.yaml`) workflows run on a schedule and do not produce per-PR checks, so they should not be added as required.
+The scaffold-rename workflow (`scaffold-test.yml`) also runs on every PR to `main` and emits a `scaffold` check. Add it too if you want the customize-step validation to gate merges:
+
+- `scaffold`
 
 ## Dependabot reviewer
 

docs/github-workflows.md

@@ -1,6 +1,8 @@
 # GitHub Workflows
 
-This project uses four GitHub Actions workflows to automate testing, security scanning, template synchronization, and releases.
+This project uses three GitHub Actions workflows to automate testing, scaffold validation, and releases.
+
+Dependency CVE scanning is left to GitHub's native Dependabot security alerts (enable them under **Settings > Code security**), with `tox -e security` (`pip-audit`) available for on-demand local scans. Pulling later template changes into a scaffolded repo is a deliberate, manual step (fetch the template remote and cherry-pick), not an automated job.
 
 ## Test Workflow
 
@@ -14,40 +16,18 @@ This project uses four GitHub Actions workflows to automate testing, security sc
 
 **Requirements:** None. This workflow uses only public GitHub Actions and requires no secrets.
 
-## Security Scan Workflow
+## Scaffold Rename Workflow
 
-**File:** `.github/workflows/security-scan.yaml`
+**File:** `.github/workflows/scaffold-test.yml`
 
 **Triggers:**
-- Scheduled: Every Monday at 9:00 AM UTC
-- Manual dispatch (can be triggered from any branch)
-
-**Purpose:** Performs CVE vulnerability scanning on the local package using pip-audit via tox. The workflow builds the package and scans its dependencies for known vulnerabilities.
-
-**Requirements:** None. Uses only the default `GITHUB_TOKEN` with read permissions.
-
-## Template Sync Workflow
+- Push to `main`
+- Pull request to `main`
+- Manual dispatch
 
-**File:** `.github/workflows/template-sync.yaml`
+**Purpose:** Copies the template to a scratch directory, runs `bin/customize.sh` against the copy, and runs tox on the renamed scaffold. This proves the customize step still produces a green plugin end to end. It emits a per-PR check named `scaffold`.
 
-**Triggers:**
-- Scheduled: Every Thursday at 9:00 AM UTC
-- Manual dispatch (can be triggered from any branch)
-
-**Purpose:** Keeps this repository in sync with the upstream template repository ([mloda-plugin-template](https://github.com/mloda-ai/mloda-plugin-template)). The workflow:
-1. Checks if there are new commits in the template repository
-2. If new commits exist, creates a branch `chore/template-sync-YYYY-MM-DD`
-3. Merges template changes into the branch
-4. Opens a pull request for review
-
-**Requirements:** None. Uses only the default `GITHUB_TOKEN` with write permissions for contents and pull-requests.
-
-**Note:** If merge conflicts occur, the workflow will fail and manual resolution is required. Run locally:
-```bash
-git remote add template https://github.com/mloda-ai/mloda-plugin-template.git
-git fetch template
-git merge template/main
-```
+**Requirements:** None. Uses only public GitHub Actions and requires no secrets.
 
 ## Release Workflow