fix(ci): inline system-map dispatch for this public repo

[that-guy-wade]

Description

The system-map workflow has failed on every PR in this repo since it was installed, with a startup error:

Invalid workflow file: .github/workflows/system-map.yml#L24
error parsing called workflow "ORO-AI/.github/.github/workflows/sync-system-map.yml@main": workflow was not found.

Root cause: this repo is public, and the shared system-map dispatcher lives in the private ORO-AI/.github repo. GitHub does not allow a public repository to call a private repository's reusable workflow, so the thin uses: caller (which works fine in the private mapped repos) can never resolve the workflow here. Consequence: this repo's changes never reach the system map, and every PR shows a red system-map check.

Changes Made

• Inlined the dispatcher's two steps directly into .github/workflows/system-map.yml (diff the PR's changed files → repository_dispatch to oro-system-map when files changed and the MAP_SYNC_PAT secret is present), removing the cross-repo private reusable-workflow dependency.
• Behaviour is identical to the shared dispatcher; the private mapped repos keep using the reusable caller unchanged.
• Added a comment cross-referencing the shared dispatcher so the two stay in sync.

Issue Link

• Related to: N/A (CI ops fix)
• Closes: N/A

Testing

Manual Testing

• Validated the workflow YAML parses (single dispatch job, pull_request trigger).
• Note: a pull_request run uses the workflow from the base branch, so this new version is first exercised on the next PR after merge to main; that run should dispatch a source-pr event to oro-system-map (visible as an update-from-source run there) instead of the current startup failure.

Test Results: YAML valid; job dispatch, trigger pull_request.

Automated Testing

Test Command(s):

python -c "import yaml; yaml.safe_load(open('.github/workflows/system-map.yml'))"

Documentation

• README updated
• Code comments added/updated
• API documentation updated
• Configuration documentation updated
• Other documentation updated (please specify):

Documentation Changes:

Header comment explains the public-repo constraint and points at the shared dispatcher to keep in sync.

Checklist

• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings or errors
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been published and merged

Additional Notes

Follow-up option (not done here): if more public repos need the map sync, or the dispatcher starts changing, relocate the shared dispatcher to a public workflows repo and repoint all callers — that restores a single source of truth. For now the dispatcher is effectively frozen, so inlining is the low-cost fix.

🤖 Generated with Claude Code

Greptile Summary

The PR replaces an unusable cross-repository reusable-workflow call with an inline job that collects changed PR files and dispatches a source-pr event to the system-map repository.

• Skips fork-originated pull requests and dispatches only when changed files and MAP_SYNC_PAT are present.
• Serializes repository, PR, commit, and changed-file metadata into the dispatch payload.
• Introduces a mutable third-party action reference that handles the cross-repository PAT.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking recommendation to pin the PAT-consuming third-party action to an immutable commit.

The inline workflow removes the inaccessible reusable-workflow dependency, while its remaining concern is the supply-chain exposure created by passing the dispatch PAT to an action selected through a mutable tag.

Files Needing Attention: .github/workflows/system-map.yml

Security Review

The new dispatch step supplies MAP_SYNC_PAT to peter-evans/repository-dispatch@v3, whose mutable tag leaves the token exposed to a future compromised or repointed action revision. How this was verified: The changed step resolves a mutable @v3 reference and passes the PAT directly through its token input.

Important Files Changed

Filename	Overview
.github/workflows/system-map.yml	Inlines the changed-file dispatch flow correctly, but the PAT-consuming third-party action should be pinned to an immutable commit.

Prompt To Fix All With AI

### Issue 1
.github/workflows/system-map.yml:48
**Mutable action handles repository PAT**

The workflow passes `MAP_SYNC_PAT` to `peter-evans/repository-dispatch@v3`, whose mutable tag can be repointed without this repository changing, exposing the token to unreviewed action code. Pin the action to a full commit SHA to keep the executed code immutable.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix(ci): inline system-map dispatch for ..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

Mutable action handles repository PAT

The workflow passes MAP_SYNC_PAT to peter-evans/repository-dispatch@v3, whose mutable tag can be repointed without this repository changing, exposing the token to unreviewed action code. Pin the action to a full commit SHA to keep the executed code immutable.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/system-map.yml
Line: 48

Comment:
**Mutable action handles repository PAT**

The workflow passes `MAP_SYNC_PAT` to `peter-evans/repository-dispatch@v3`, whose mutable tag can be repointed without this repository changing, exposing the token to unreviewed action code. Pin the action to a full commit SHA to keep the executed code immutable.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[shardi-b]

Review: PR #272 — fix(ci): inline system-map dispatch for this public repo

Decision: approve. No blocking (≥80) findings.

What the PR does

Replaces an unusable cross-repo reusable-workflow call (a public repo cannot call the private ORO-AI/.github reusable workflow, which failed every PR with "workflow was not found") with an inlined dispatch job in .github/workflows/system-map.yml. The job collects the PR's changed files via gh pr diff --name-only and dispatches a repository_dispatch (source-pr) event to ORO-AI/oro-system-map, guarded on non-fork PRs, a non-empty file list, and the presence of MAP_SYNC_PAT.

Correctness assessment (no defects found)

• Secret-in-if pattern is valid. MAP_SYNC_PAT is set as a job-level env, then the dispatch step tests env.MAP_SYNC_PAT != ''. The env context is available in step-level if conditions, and routing a secret through env is the sanctioned workaround for secrets not being usable in if. Works as intended.
• Failure handling is correct. GitHub's default run: shell uses -eo pipefail, so a gh pr diff failure fails the step; the files=$(...) command substitution under set -e also aborts on error. Failing loudly is the desired behavior.
• Permissions are sufficient. contents: read + pull-requests: read cover gh pr diff --name-only (REST /pulls/{n}/files); no actions/checkout is required since gh uses the API.
• Payload is injection-safe and valid. client-payload wraps repo/sha/files in toJSON(), which emits properly escaped JSON strings; the multi-line | block is valid JSON. github.event.number and the fork guard are valid on pull_request.

Non-blocking observations (intentionally not raised as blocking findings)

• Unpinned third-party action (peter-evans/repository-dispatch@v3). Greptile suggested pinning to a commit SHA because the action receives the PAT. This is reasonable hardening, but every other action in this repo's workflows uses mutable major-version tags (actions/checkout@v4, docker/build-push-action@v5, astral-sh/setup-uv@v7, etc.), so requiring a SHA pin here would break with established convention rather than fix a defect. Below threshold.
• Space-joined files string. Filenames are joined with spaces (tr '\n' ' '), so a filename containing a literal space would be ambiguous to the consumer. Extremely rare in a code repo and plausibly matches the prior dispatcher's format; low severity.
• Unverifiable parity with the shared dispatcher. The PR claims behavioral identity with the private ORO-AI/.github dispatcher, but that repo isn't visible here, so payload/event-type parity can't be confirmed. Low confidence; not actionable from this diff.

None of these reach the blocking threshold, so the change is approved.