Skip to content

hypatia-scan.yml: migrate to standards reusable workflow once it gains SARIF upload, PR comments, and gitbot-fleet submission #57

Description

@hyperpolymath

Context

governance.yml and scorecard.yml already call the shared reusable workflows in hyperpolymath/standards (governance-reusable.yml, scorecard-reusable.yml). The natural next step is to do the same for hypatia-scan.yml.

That migration is currently blocked: the hyperpolymath/standards/.github/workflows/hypatia-scan-reusable.yml reusable workflow (checked at both @main and the pinned @5a93d9d57cc04de4002d6d0ecd336fc7a8698910) is strictly less capable than our inline hypatia-scan.yml. Converting now would silently drop three audited capabilities.

Capability gap

Capability inline hypatia-scan.yml (current main) standards/hypatia-scan-reusable.yml
Run Hypatia scan ✅ (also adds panic-attack assail + caching)
Upload SARIF → Security / Code-scanning ✅ (security-events: write) ❌ no SARIF step; security-events: read only
Comment findings on PR ✅ (pull-requests: write) ❌ no step, no permission
Submit to gitbot-fleet (Phase-2 learning)

The inline permission grants are deliberately documented inside hypatia-scan.yml:

  • SARIF upload to code scanning → hyperpolymath/burble#35
  • Dependabot alert reads (DA001DA004) → 007-lang/audits/audit-dependabot-automation-gap-2026-04-17.md

This is why governance.yml/scorecard.yml were moved to reusable workflows but hypatia-scan.yml was intentionally kept inline.

Unblock condition

Migrate hypatia-scan.yml to the reusable caller once hyperpolymath/standards/.github/workflows/hypatia-scan-reusable.yml gains:

  1. SARIF conversion + github/codeql-action/upload-sarif upload, declared with security-events: write;
  2. a "comment on PR with findings" step, declared with pull-requests: write;
  3. gitbot-fleet Phase-2 finding submission.

Once those land upstream, the caller here can shrink to a ~20-line workflow_call wrapper — but it must still grant security-events: write and pull-requests: write (a reusable workflow's effective token permissions are capped by the caller).

History

PR #54 attempted this conversion but granted only security-events: read with no pull-requests permission, which would have broken SARIF upload and PR commenting. That PR is being closed as superseded (its foundry Wave-1 work already landed on main via be17f66); this issue preserves the migration intent.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions