docs: correct admiralty ancestry status

[Freudator86]

Intent

Correct a stale claim in docs/admiralty-fleet-repo.md's 'What is not built yet' section. The doc asserted the merge-bump procedure had not been applied and that a vessel at the pin could not fast-forward onto admiralty, backed by a 2026-08-01 measurement (pin de0b95b not an ancestor of admiralty main 285289c). Re-measured 2026-08-05 in a throwaway clone of Freudator86/admiralty (outside the worktree, deleted afterward) with this fork fetched in: admiralty main is now d16bf0c, its pin is b5c0bf6, and the pin-bump commit 4bf4acf is a true two-parent merge (fork's b5c0bf6 as second parent), so git merge-base --is-ancestor b5c0bf6 d16bf0c now exits 0 - the claim is stale and the procedure has been applied. Replaced the old measurement with the new one in the same form (exact commands, commits, results), kept the ancestry-vs-tree distinction the section makes, and noted the same open question (restoring ancestry as the fork advances further) now recurs at each future pin bump rather than being unsolved. Did not touch docs/fork-patches.md, which is out of scope. This is a docs-only change to firstmate's own shared tracked material.

What Changed

• Captain, corrected docs/admiralty-fleet-repo.md to state that admiralty has now applied the merge-bump procedure for the newer fork pin.
• Replaced the stale 2026-08-01 ancestry measurement with the verified 2026-08-05 d16bf0c / b5c0bf6 measurement and merge-parent evidence.
• Clarified that future fork advancement past each pin still requires its own ancestry-restoring merge.

Risk Assessment

✅ Low: Captain, this is a narrow docs-only correction that replaces stale measured evidence with a current, internally consistent measurement and keeps the remaining open risk scoped to future pin bumps.

Testing

I inspected the exact doc diff, confirmed the repository’s changed-file test selector maps this docs-only change to no automated tests, then produced end-to-end Git-history evidence from temporary admiralty clones showing the pin is now an ancestor of admiralty main and the old stale wording is absent; the temporary clones were removed and no working-tree artifacts remain.

Evidence: Admiralty ancestry verification transcript

$ git clone --no-checkout https://github.com/Freudator86/admiralty.git <worktree-temp>
Cloning into '.tmp-admiralty-verify-1209313'...

$ git remote add fork https://github.com/Freudator86/firstmate.git

$ git fetch --quiet origin main

$ git fetch --quiet fork main:refs/remotes/fork/main

$ git rev-parse origin/main
d16bf0cd19c316376f77615f46fd0e8e85fde45a

$ git cat-file -p 4bf4acfd3f9eb5ad6edc99e84c2221843f0b500b | sed -n "1,6p"
tree 5ddd2103a4a116a2d213e51ccd65d347d625acaa
parent 92093e8d1c9f85b2693aa36e1e3fd2a6442ecd0d
parent b5c0bf65d43ca274e8f8ae3b700426d614e7585c
author Coditan-XO <coditan-xo@fleet.local> 1785855776 +0000
committer Coditan-XO <coditan-xo@fleet.local> 1785855789 +0000


$ git merge-base --is-ancestor b5c0bf65d43ca274e8f8ae3b700426d614e7585c d16bf0cd19c316376f77615f46fd0e8e85fde45a; echo exit=$?
exit=0

$ git merge-base --is-ancestor b5c0bf65d43ca274e8f8ae3b700426d614e7585c fork/main; echo exit=$?
exit=0

$ git rev-list --count b5c0bf65d43ca274e8f8ae3b700426d614e7585c..fork/main
36

$ git log --format="%h %cs %s" -1 b5c0bf65d43ca274e8f8ae3b700426d614e7585c
b5c0bf6 2026-08-04 Merge pull request #65 from Freudator86/fm/fm-watcher-cannot-read-crew-state

--- Merge-base cross-check for newest shared fork commit ---
$ git clone --no-checkout https://github.com/Freudator86/admiralty.git <worktree-temp>
Cloning into '.tmp-admiralty-verify-mergebase-1234689'...

$ git merge-base fork/main d16bf0cd19c316376f77615f46fd0e8e85fde45a
b5c0bf65d43ca274e8f8ae3b700426d614e7585c

$ git rev-list --count $(git merge-base fork/main d16bf0cd19c316376f77615f46fd0e8e85fde45a)..fork/main
36

Evidence: User-visible doc excerpt and stale-wording check

$ sed -n "154,170p" docs/admiralty-fleet-repo.md
  Ancestry is a property of the commit graph and not of tree content, so a pin bump alone does not restore it: a bump commit on `admiralty` copies the fork's newer tree, but it does not add the fork's newer commits to `admiralty`'s ancestor set.
  Absorbing that history so an already-updated vessel stays fast-forwardable needs a true merge of the fork's `main` into `admiralty`'s `main`, which is consistent with the standing rule that upstream-sync pull requests land as true merge commits rather than squashes.
  How such a merge interacts with the drift gate is no longer the open part: `admiralty`'s own `fleet/doctrine/pin-and-bump.md` owns the merge-bump procedure, including regenerating the manifest in that same commit and the verification to put in the pull request.
  **The procedure has since been applied.**
  `admiralty`'s `chore(pin): bump vendored firstmate to b5c0bf6` (commit `4bf4acfd3f9eb5ad6edc99e84c2221843f0b500b`, 2026-08-04) lands as a true merge: its second parent is this fork's `b5c0bf65d43ca274e8f8ae3b700426d614e7585c`, so `admiralty`'s ancestor set now includes the fork's history up to that commit, not just its tree.
  A vessel sitting exactly at that pin can now fast-forward onto `admiralty`.
  Measured on 2026-08-05 UTC in a throwaway clone of `Freudator86/admiralty` whose `main` was `d16bf0cd19c316376f77615f46fd0e8e85fde45a`, with this fork fetched into it so both sides are present: `git merge-base --is-ancestor b5c0bf65d43ca274e8f8ae3b700426d614e7585c d16bf0cd19c316376f77615f46fd0e8e85fde45a` exits 0.
  Name the `admiralty` commit rather than a bare `origin/main`, because inside that clone `origin` is `admiralty`, while in this repository `origin` is the fork; the same command against the wrong side answers a different question.
  The newest fork commit that is an ancestor of that `admiralty` `main` is the pin itself, `b5c0bf6`, dated 2026-08-04: the merge absorbed the fork's history exactly up to the commit it pinned, no further.
  This fork's `main` has since advanced past the pin again: in this same review pass, `git merge-base --is-ancestor b5c0bf65d43ca274e8f8ae3b700426d614e7585c origin/main` exits 0 and `git rev-list --count b5c0bf65d43ca274e8f8ae3b700426d614e7585c..origin/main` reports 36 commits.
  The same open question - restoring ancestry as the fork keeps moving - recurs at every pin bump, and each one needs its own merge, not just the first.
  That merge bump cannot be raised through no-mistakes, because its rebase would flatten the ancestry the merge exists to create, so each one is authorized on the captain's word instead.
- The Bridge extraction, the fork-maintenance tooling retirement, and the Bucket-A upstreaming are unstarted; the fork-first ratchet prices each as its own reviewed pin bump.

$ rg -n "procedure has not been applied|cannot fast-forward onto `admiralty`|285289c|de0b95b" docs/admiralty-fleet-repo.md; echo exit=$?
exit=1

Evidence: Changed doc excerpt

HEAD: af59be6f538a2144aecf83a1c3c156e708adf3eb
Base: 7778ca3246868064e4e33531174a5032f705fb76

Changed doc excerpt:
  Ancestry is a property of the commit graph and not of tree content, so a pin bump alone does not restore it: a bump commit on `admiralty` copies the fork's newer tree, but it does not add the fork's newer commits to `admiralty`'s ancestor set.
  Absorbing that history so an already-updated vessel stays fast-forwardable needs a true merge of the fork's `main` into `admiralty`'s `main`, which is consistent with the standing rule that upstream-sync pull requests land as true merge commits rather than squashes.
  How such a merge interacts with the drift gate is no longer the open part: `admiralty`'s own `fleet/doctrine/pin-and-bump.md` owns the merge-bump procedure, including regenerating the manifest in that same commit and the verification to put in the pull request.
  **The procedure has since been applied.**
  `admiralty`'s `chore(pin): bump vendored firstmate to b5c0bf6` (commit `4bf4acfd3f9eb5ad6edc99e84c2221843f0b500b`, 2026-08-04) lands as a true merge: its second parent is this fork's `b5c0bf65d43ca274e8f8ae3b700426d614e7585c`, so `admiralty`'s ancestor set now includes the fork's history up to that commit, not just its tree.
  A vessel sitting exactly at that pin can now fast-forward onto `admiralty`.
  Measured on 2026-08-05 UTC in a throwaway clone of `Freudator86/admiralty` whose `main` was `d16bf0cd19c316376f77615f46fd0e8e85fde45a`, with this fork fetched into it so both sides are present: `git merge-base --is-ancestor b5c0bf65d43ca274e8f8ae3b700426d614e7585c d16bf0cd19c316376f77615f46fd0e8e85fde45a` exits 0.
  Name the `admiralty` commit rather than a bare `origin/main`, because inside that clone `origin` is `admiralty`, while in this repository `origin` is the fork; the same command against the wrong side answers a different question.
  The newest fork commit that is an ancestor of that `admiralty` `main` is the pin itself, `b5c0bf6`, dated 2026-08-04: the merge absorbed the fork's history exactly up to the commit it pinned, no further.
  This fork's `main` has since advanced past the pin again: in this same review pass, `git merge-base --is-ancestor b5c0bf65d43ca274e8f8ae3b700426d614e7585c origin/main` exits 0 and `git rev-list --count b5c0bf65d43ca274e8f8ae3b700426d614e7585c..origin/main` reports 36 commits.
  The same open question - restoring ancestry as the fork keeps moving - recurs at every pin bump, and each one needs its own merge, not just the first.
  That merge bump cannot be raised through no-mistakes, because its rebase would flatten the ancestry the merge exists to create, so each one is authorized on the captain's word instead.
- The Bridge extraction, the fork-maintenance tooling retirement, and the Bucket-A upstreaming are unstarted; the fork-first ratchet prices each as its own reviewed pin bump.

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

🔧 **Review** - 1 issue found → auto-fixed ✅

• ⚠️ docs/admiralty-fleet-repo.md:163 - The new paragraph says the fork has advanced past the b5c0bf6 pin again and points to the top of the section for that fact, but the earlier concrete tip still says ce43899, which is an ancestor of b5c0bf6. Update the surrounding measurement/current-tip text or remove the parenthetical so the renewed divergence claim is backed by a current post-pin commit.

🔧 Fix: Captain, document verified post-pin fork advancement
✅ Re-checked - no issues remain.

✅ **Test** - passed

✅ No issues found.

• git diff 7778ca3246868064e4e33531174a5032f705fb76..af59be6f538a2144aecf83a1c3c156e708adf3eb -- docs/admiralty-fleet-repo.md
• bin/fm-test-run.sh --list --changed --base 7778ca3246868064e4e33531174a5032f705fb76
• bin/fm-test-run.sh --changed --base 7778ca3246868064e4e33531174a5032f705fb76
• Temporary in-worktree clone of Freudator86/admiralty, with Freudator86/firstmate fetched as fork/main, verifying origin/main == d16bf0cd19c316376f77615f46fd0e8e85fde45a, commit 4bf4acfd3f9eb5ad6edc99e84c2221843f0b500b has second parent b5c0bf65d43ca274e8f8ae3b700426d614e7585c, and git merge-base --is-ancestor b5c0bf65d43ca274e8f8ae3b700426d614e7585c d16bf0cd19c316376f77615f46fd0e8e85fde45a exits 0
• Temporary in-worktree clone cross-check that git merge-base fork/main d16bf0cd19c316376f77615f46fd0e8e85fde45a returns b5c0bf65d43ca274e8f8ae3b700426d614e7585c and that fork/main is 36 commits past that pin
• sed -n '154,170p' docs/admiralty-fleet-repo.md plus rg -n 'procedure has not been applied|cannot fast-forward onto admiralty|285289c|de0b95b' docs/admiralty-fleet-repo.md
• find . -maxdepth 1 -type d -name '.tmp-admiralty-verify-*' -print && git status --short

✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.