Landed work on seven paths left the default branch under a commit that describes a workflow pin comment

[iderex]

What is wrong

One commit on the default branch removed landed work on seven paths under a
message that describes a change to how one workflow pin is commented. Six of
those paths are still missing. The seventh is #154.

git show --stat --format='%H%nparents %P%n%s' d3edfc95b8526033c79cb26afe48282c2c090e32
d3edfc95b8526033c79cb26afe48282c2c090e32
parents 90656ba77a7c930d04d2205b2dd99df787853a92
Name the version the pinned commit actually is (#151)

 .github/workflows/codeql.yml       |  16 -
 .github/workflows/scorecard.yml    |   2 +-
 .github/workflows/zizmor.yml       |  19 +-
 LICENSE                            | 661 -------------------------------------
 README.md                          |   6 -
 cmd/notices/tree_test.go           | 289 ----------------
 docs/operator-guide.md             |  15 +-
 docs/quality-parity.md             | 428 +-----------------------
 internal/contexts/contexts.go      |   7 +-
 internal/contexts/contexts_test.go |  20 --
 10 files changed, 13 insertions(+), 1450 deletions(-)

Its parent is the merge that carried the licence in, so this is not a branch
that was cut before the work existed and merged without conflict. It is a commit
whose tree was taken from an older state of the default branch and pushed on top
of the newer one, so the merge that landed it replaced seven paths with what they
had said earlier. It arrived through #135:

git log -1 --format='%H%nparents: %P%n%s' 8946969a35e29ca4f3c423859360c4fc51ab4852
8946969a35e29ca4f3c423859360c4fc51ab4852
parents: 90656ba77a7c930d04d2205b2dd99df787853a92 d3edfc95b8526033c79cb26afe48282c2c090e32
Merge pull request #135 from Flowfin/dependabot/github_actions/github/codeql-action/upload-sarif-4.37.6

Nothing red followed it. The suite is green on the default branch today, because
almost everything removed is prose and the one test that went with it was the
only thing reading the code path it covered.

What the evidence is

The whole of what the default branch is missing, measured against the commit
before it, with the security policy that landed afterwards showing as the one
addition:

git diff --stat 90656ba77a7c930d04d2205b2dd99df787853a92 origin/main
 .github/workflows/codeql.yml       |  16 -
 .github/workflows/scorecard.yml    |   2 +-
 .github/workflows/zizmor.yml       |  19 +-
 LICENSE                            | 661 -------------------------------------
 README.md                          |   6 -
 SECURITY.md                        | 144 ++++++++
 cmd/notices/tree_test.go           | 289 ----------------
 docs/operator-guide.md             |  15 +-
 docs/quality-parity.md             | 428 +-----------------------
 internal/contexts/contexts.go      |   7 +-
 internal/contexts/contexts_test.go |  20 --
 11 files changed, 157 insertions(+), 1450 deletions(-)

Path by path, what is gone and which issue it was landed for.

LICENSE and the ## License section of README.md, landed in
5615b762b087b15ce541bca4bde3fbf1f5818afc for #149. The board is public and
carries no licence again, which is the state #148 is open about:

git ls-tree --name-only origin/main | grep -c '^LICENSE'
0

docs/quality-parity.md, two sections. The three names this tree declares and
the two more with no verdict, landed for #26, and the whole of
## Which contexts arrive, and on which pull requests, landed for #62. The
document went from 631 lines to 209:

git show 90656ba:docs/quality-parity.md | wc -l
631
git show origin/main:docs/quality-parity.md | wc -l
209

internal/contexts/contexts.go and internal/contexts/contexts_test.go, landed
for #26. The zizmor entry is back to giving the shared reason and naming #26 as
what ends it, and TestAPermanentAbsenceDoesNotRestOnAReasonThatEnds is gone,
so the entry that reason was written to replace is refused by nothing:

git grep -c 'TestAPermanentAbsenceDoesNotRestOnAReasonThatEnds' origin/main -- internal/contexts/contexts_test.go ; echo "exit=$?"
exit=1

.github/workflows/codeql.yml, sixteen comment lines landed for #26 saying why a
pin comment names the exact version rather than the major, and naming the audit
that holds it. The pins themselves are unaffected and still name v4.37.6, so what
is missing is the reason and not the state:

git grep -nE 'uses: .*@[0-9a-f]{40} # v[0-9]+$' origin/main -- .github/workflows/ ; echo "exit=$?"
exit=1

.github/workflows/zizmor.yml, in two directions at once. The pin moved forward
to v4.37.6 and stays there, and the comment above it went back to listing a pin
comment that disagrees with its commit as a low-severity hygiene finding the
gate does not collect. The regular persona reports that at medium and the step
below fails the build on it, which is what #151 was raised by.

docs/operator-guide.md, fifteen lines landed for #42 in
f11384c, where two pastes no longer reproduced. Both are back to the form that
did not reproduce, including a git grep -n whose pasted line number is what
that repair removed.

What done looks like

Each of the six paths back to what the default branch held at
90656ba77a7c930d04d2205b2dd99df787853a92, except zizmor.yml and
scorecard.yml, where the pin stays at v4.37.6 and only the comment goes back.

Not as one change. Each path belongs to an issue that argued it, and a single
commit restoring all six would land five issues' work under one reason. What
holds them together is this issue rather than a branch.

The reading that has to survive the repair is that a restored file is the bytes
that were there rather than a retyping of them. For a path that was deleted
outright, that is a blob comparison and the two hashes are equal afterwards:

git rev-parse 90656ba:<path>
git hash-object <path>

For a path that has moved forward since, it is not, and taking the whole blob
would drop the work that arrived after the removal. docs/quality-parity.md is
in that state: #156 adds a row to the pull-request parameter table, well below
both removed sections, so the repair there is to insert the two sections and to
expect the hashes to differ. Read the diff rather than the hash on that one.

There is a second thing to decide here and it is the one that matters more than
the six files. Nothing on this board noticed a merge deleting a licence, a
guard and four hundred lines of a document. The pull request checks read the
tree the change produces and not what the change removed, and a merge whose
result compiles and passes says nothing about what it replaced. Whether anything
here should refuse a merge that removes a tracked path without saying so in its
body is not decided by restoring the files, and it is the reason this is one
issue rather than six comments.