chore(library): base the credentials branch on the library's master

The Phase 2 library commit was made on a branch cut from 59c11ed -- the
nsec key-store commit, which is what the app's curated branch pins -- but
that commit is not the library's default branch's tip: master is at
e51e3ae, the merge of PR #1 that brought 59c11ed in. The two trees are
identical, so the rebase is content-free; what changes is that
claude/nostr-credentials is now one commit ahead of master rather than a
sibling of its tip, and the app's pointer follows it to 84cc44c.

The plan said the nsec library commit "sits on a remote branch called
detached", which was true of where it was found and false of where it is:
it reached master through the PR. What is still true, and still the
rollout's one hard step, is that it is untagged -- the library has no tags
at all -- and JitPack consumers resolve by tag. The two sentences that said
otherwise are corrected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pulled-From: curated/curated@00c36ec509
This commit is contained in:
Kgothatso Ngako
2026-09-12 22:15:19 +02:00
parent 042c5db5f4
commit 89e364c1bd

View File

@@ -36,10 +36,12 @@ floating action button's label by text has to search the unmerged tree, because
on the merged tree an `assertDoesNotExist` for a hidden control is vacuously true.
`ReadOnlyEntrancesJvmTest` uses the unmerged tree for every lookup for that reason.
The library commit is on `claude/nostr-credentials` in the submodule, at `01962f3`,
bumped into the app by the Phase 2 commit; like the nsec plan's `59c11ed` before
it, it has to be pushed with this branch and tagged for JitPack consumers before any
of this leaves the machine. Phase 8 below says why the two go out on one tag.
The library commit is on `claude/nostr-credentials` in the submodule, at `84cc44c`,
one commit ahead of the library's `master` and bumped into the app by the Phase 2
commit; it has to be pushed with this branch and tagged for JitPack consumers
before any of this leaves the machine. The nsec plan's `59c11ed` reached `master`
through the library's PR #1 but was never tagged; Phase 8 below says why the two go
out on one tag.
## The constraint
@@ -834,11 +836,12 @@ same id, same metadata.
## Phase 8 — rollout
**Library first, and on the tag the nsec work still owes.** Phase 2 is a commit
on the submodule, reaching the app as a pointer bump in the Phase 3 commit. The
library commit that introduced `nostr-keys.dat` is untagged and sits on a remote
branch called `detached`; the nsec plan says it has to be pushed and tagged before
any of that work leaves the machine, and Phase 2 goes out on the same tag, so that
no JitPack consumer ever sees the v1 file without the reader that migrates it.
on the submodule, reaching the app as a pointer bump in the Phase 2 commit. The
library commit that introduced `nostr-keys.dat` is on the library's `master` — it
arrived through PR #1 — but is untagged, and the library has no tags at all; the
nsec plan says it has to be tagged before any of that work leaves the machine, and
Phase 2 goes out on the same tag, so that no JitPack consumer ever sees the v1 file
without the reader that migrates it.
**Phase 1 ships alone.** A type change with two `require`s and one exhaustive
`when`; if the release after it behaves differently, the cause is in one diff.