chore(ci): enroll in org-wide secret-scan reusable workflow (Molecule-AI/molecule-core#2109)

[HongmingWang-Rabbit]

[Molecule-Platform-Evolvement-Manager]

3-line enrollment in the canonical secret-scan workflow shipped in EnterOS-AI/enter-os-core#2109. Defense against the #2090-class leak (a hosted-agent commit slipping a credential-shaped string into a PR — caught at the PR layer, before merge).

High priority for this repo: per the org audit-log review, docs was the #2 most-touched repo by the hosted Copilot Coding Agent (170 events / 7d, behind only molecule-core's 1,781). Public-facing docs are also the surface most likely to embed example tokens / API keys that LOOK fake but match real patterns.

Pattern set lives in molecule-core; updates ride along automatically.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	Apr 29, 2026 9:00am

[HongmingWang-Rabbit]

[Molecule-Platform-Evolvement-Manager]

Investigation summary

secret-scan job is failing here but I cannot diagnose the actual matched pattern — reusable-workflow logs return BlobNotFound when fetched via the consumer repo's API, and gh run view --log-failed returns 0 lines. Reproduced the workflow's logic locally:

• git diff --name-only --diff-filter=AM main..HEAD returns 2 files: the workflow itself (SELF-excluded) and INCIDENT_LOG.md
• For each file, scanned added lines (git diff --no-color --unified=0 main..HEAD -- <file> | grep -E '^\+[^+]') against every pattern in the canonical workflow's pattern set
• Zero matches

Whole-tree scan of the entire docs repo also returns zero matches against any pattern. The 36 sibling rollout PRs (plugins/templates/org-templates) all passed secret-scan cleanly.

Hypothesis

GitHub Actions environment (Ubuntu / GNU grep) may behave differently from local replication on a specific file. Likely candidates: line-ending handling in the merge commit, encoding, or a pre-existing pattern in a docs example file that triggers fallback whole-tree mode when the BASE SHA isn't reachable from the shallow clone.

Asks for the reviewer

1. Open the workflow run in the browser — https://github.com/Molecule-AI/docs/actions/runs/24974569493 — the GitHub web UI surfaces logs that the API doesn't. The exact <file> (matched: <pattern>) line at the end of the failure block tells us the culprit immediately.
2. If the matched file is a docs example (e.g., a tutorial showing a fake-but-pattern-matching token): either scrub the value to a placeholder like ghs_EXAMPLE_DO_NOT_USE_xxx, OR add the file path to the SELF-exclude list in the canonical workflow.
3. If the failure is workflow-internal (e.g., fatal: shallow clone): bump fetch-depth in the canonical workflow's checkout step from 2 to 0, or add a robustness fix.

Not blocking on this — the rollout itself worked across 36/36 sibling repos. This one's a docs-specific edge case.

[HongmingWang-Rabbit]

[Molecule-Platform-Evolvement-Manager] Update

Fresh CI rerun after empty-commit push (sha=543906e) still fails immediately, no script output. Re-confirmed:

• Local replication of the workflow logic finds zero matches in either the diff or the whole tree
• gh api repos/Molecule-AI/docs/actions/jobs/<id>/logs returns BlobNotFound even when fetched <1 min after job completion
• gh run view --log returns 0 bytes for this run
• actions/permissions/workflow is identical to landingpage / molecule-controlplane / molecule-ai-workspace-runtime / molecule-ai-plugin-superpowers (all of which pass the same workflow cleanly)

The instant-failure-with-no-output pattern strongly suggests a setup-time error before the script block runs — possibly something in the runner's reusable-workflow resolution path that's docs-specific. Since logs are unrecoverable from the consumer side, the only path forward is the GitHub Actions web UI which has separate log-access semantics.

Leaving this PR open. The 36/36 sibling rollouts (plugin/template/org-template repos) all pass cleanly, so the canonical workflow itself is fine. If a docs admin can grab the actual error message from the web UI that's the unblock; otherwise we may need to skip this repo or add explicit workflow_dispatch + actions/checkout fetch-depth: 0 to the consumer to gather more diagnostic data.