Add scheduled security scan workflow

files/AGENTS.md

@@ -20,6 +20,7 @@ PROJECT_NAME: PROJECT_DESCRIPTION
 - After pushing commits that trigger a Gitea workflow, poll the workflow run until it succeeds. If it fails or is cancelled, inspect the failing job/logs, fix the issue when in scope, push again, and repeat the workflow check loop. Fixing and pushing a workflow failure is not a stopping point.
 - When the project uses `blueprint.md` and `blueprint.json` for README generation, keep the rainbow `{{ template:section-line }}` divider between major README sections. Do not replace it with plain `---` unless the target renderer cannot display inline images.
 - If README blueprint files are changed, regenerate or update `README.md` in the same change and verify the generated output renders reasonably.
+- For releasable projects, add or preserve `.gitea/workflows/security-scan.yml` using `files/security-scan-gitea.yml` unless the repository already has equivalent scheduled security automation.
 
 ## Commands
 
@@ -54,6 +55,7 @@ ARTIFACT_NAME
 
 - Review `docs/security-review.md` before release work.
 - Fill `docs/security-review.md` with actual checked commands and results when performing release-readiness work.
+- Review scheduled security workflow failures before changing code. Treat matches as leads: they may be true positives, documentation examples, or test fixtures.
 - Treat generated credentials and config files as sensitive.
 - Keep external network calls documented.
 - Prefer local processing for user data.