audit: findings from the 2026-10-17 fleet read #38

Findings for this repo from the 2026-10-17 fleet read, each re-verified against
origin/main at 205a987 before being listed. All four items from the
original notes reproduce and are listed; two are reframed because the evidence
says something more specific than the note did. Nothing here is fixed by this
issue.

Labelled defect (behaviour is wrong) or doc-rot (a statement is false).

1. defect — the required ok check runs no tests, so the reusable commit-email check is uncovered

.github/workflows/ci.yml has one job whose one step is echo "ok"
(lines 15-20 at 205a987), and the org ruleset require-ci-ok requires the
context ok. tests/commit-email.test.sh is referenced by nothing under
.github/:

$ grep -rn 'commit-email.test' .github/
(no output)

So the only automated test in the repo never runs in CI, and the run: block of
a reusable workflow that other repos are meant to depend on is ungated. The test
itself works — 7 cases, all passing:

$ bash tests/commit-email.test.sh
ok   - work-address commit passes (exit 0)
ok   - personal-address commit fails (exit 1)
ok   - work author, personal committer fails (exit 1)
ok   - bot identities pass (exit 0)
ok   - existing personal history is not re-checked (exit 0)
ok   - new-branch push (zero base) checks HEAD (exit 1)
ok   - personal commit below a work HEAD in the range fails (exit 1)

Demonstrated rather than inferred, by inverting the core rule in
commit-email.yml (*@"$DOMAIN") return 0 → return 1) and running both
gates against the mutation. File sha256 before d309059a…, after 30c84e9b…,
so the mutation is known to have applied:

$ bash tests/commit-email.test.sh        # with the mutation in place
FAIL - work-address commit passes (exit 1, wanted pass)
FAIL - existing personal history is not re-checked (exit 1, wanted pass)
test exit: 1

$ echo "ok"                              # ci.yml's only step, same mutation
ok
exit 0

A change that inverts the published check is caught by the test and passes the
required check. AGENTS.md is honest about this ("Do not assume CI covers
tests/commit-email.test.sh"), so it is a defect in the gate, not doc-rot.

2. defect — a caller's digest pin does not freeze detection behaviour (fleet-wide, fails open)

.github/workflows/gitleaks.yml line 68 at 205a987:

curl -fsSL "https://raw.githubusercontent.com/FlowMatrix-AI/.github/main/.gitleaks.toml"

The digest a caller pins covers gitleaks-version (an input default: in that
file) but not the ruleset the detector runs with, which is re-fetched from main
every run. Broadening the shared [allowlist] here therefore shrinks detection
in every calling repo on its next scan, with no commit, no PR and no reviewer in
any of them, while every required gitleaks / gitleaks check stays green. That
is a fail-open on a required security check.

Scope, measured by reading every non-archived repo's
.github/workflows/secret-scan.yml and extracting its uses: ref: 69 of the
70 non-archived repos call this workflow (the 70th is this one, via a local
./ ref), and 68 of those 69 pin it by digest.

#37 is open for this and changes the fetch to resolve at job.workflow_sha.
Listed here because it reproduces on origin/main and because the roll-up
should be complete, not because it is unattended.

3. doc-rot — mark.png is tracked, referenced by nothing, and the only path missing from the Architecture table

$ git ls-files -s mark.png
100644 25e968d2d9762446eae384e00308738e6e339801 0	mark.png
$ grep -rI 'mark\.png' . --exclude-dir=.git
(no output)
$ grep -c mark AGENTS.md
0

Added by 9ee1d4b ("Add files via upload"). AGENTS.md's Architecture table
lists every other top-level path in the tree and this one is absent, so the
table reads as a complete map of the repo while one tracked file is unaccounted
for.

The original note guessed it is an avatar source. That is not confirmable
from here: the org avatar is served from avatars.githubusercontent.com and the
API does not say which file it was uploaded from, so nothing in this repo or the
API can establish or refute it. Recommended fix is therefore one row in the
Architecture table saying what it is and who uses it, not a deletion — an
unreferenced binary that may be the org mark should be documented, and the
answer costs the owner one look at the org settings.

4. defect — commit-email.yml has no caller anywhere in the org, including the public repos it exists for

Searched two ways, both returning only the definition file itself:

$ gh api -X GET search/code -f q='org:FlowMatrix-AI "FlowMatrix-AI/.github/.github/workflows/commit-email.yml"'
total_count: 1   -> .github/.github/workflows/commit-email.yml
$ gh api -X GET search/code -f q='org:FlowMatrix-AI "commit-email.yml@"'
total_count: 1   -> .github/.github/workflows/commit-email.yml

Null result checked against a control on the same index, so this is not an
empty-index artifact: the equivalent query for gitleaks.yml@main returns 8
hits, and the per-repo read in finding 2 found 69 callers of the sibling
workflow.

There are four public repos in the org. None calls this check, including this
one, which is where it lives and which the header describes as its use case.
This repo's own history is what the check exists to prevent: 21 of its 36
commits are authored with a personal @gmail.com address.

The reason adoption is blocked is measurable, and is the part worth fixing
first. allowed() accepts *@$DOMAIN, [email protected],
*[bot]@users.noreply.github.com and *[email protected]. It
does not accept a human's own <id>+<login>@users.noreply.github.com, which
is the address GitHub's "Keep my email addresses private" setting produces, and
which is what this repo's configured identity uses. Run the published run:
block against such a commit:

::error::c3b7def uses [email protected] (want *@flowmatrixai.com)
exit: 1

And with that setting on, the work address cannot be pushed at all — reproduced
while opening #36:

remote: error: GH007: Your push would publish a private email address.
 ! [remote rejected] (push declined due to email privacy restrictions)

So the check as written is unsatisfiable for a contributor with email privacy
enabled: the only identity they can push is one the check rejects. Adopting it
requires either publishing work addresses on the account or allowing the
users.noreply.github.com form for humans, and that choice should be made
explicitly rather than discovered at the first push. Neither the workflow header
nor AGENTS.md mentions it.

Items from the original notes that are not listed as open

• AGENTS.md's "68 of the org's 70 active repos" with one repo named as a
  non-caller is false — 69 of 70 carry a caller and the exception is this repo —
  but it is corrected in fix(gitleaks): resolve the org ruleset at the caller's pinned ref #37, which had to rewrite the surrounding paragraph
  anyway. Not left open.