decisions + lineage: tapkeys listed beside Taproot; Orgchain v1.4 shows secrets

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H4upF5LVwmPDDqrhdUfnXh

docs/decisions.md

@@ -55,3 +55,4 @@ Format: date · decision · why. Add at the bottom. Never edit an old entry; sup
 - 2026-10-15 · **Orgchain v1.2: tapkeys and lineage's leaves.** The operator asked for the ssh, git and other keys in Orgchain, and for a tapkey rather than just an npub for each agent. A node's chain key is now its tapkey: its NIP-06 npub with the BIP-86 tweak, so one secret signs its nostr events and its chain spends, and its address follows from its npub (the tweak is checked against BIP-86's own vector). Its leaves hang off the same tree, HKDF-SHA256 with salt `lineage/v0`: an agent's ssh, git, dkim and wg keys from its nostr secret, an org's ssh-ca, mtls and noise keys from its seed. The unit tests hold values read off the key tree page for one mnemonic, and they match byte for byte. Inspect shows each node's tapkey, npub, derivation and leaves, with the public lines to paste (authorized key, `allowed_signers` line, DKIM record, WireGuard peer, CA key). Labs keyed by v1.1 keep their separate m/86' chain keys until they are reset. `@scure/base`, `bip32` and `bip39`, which came in with v1.1, now have their licenses in `public/licenses` and lines in `PROVENANCE.md`. `lineage/orgchain` main `00a3561`, time's `gh-pages` `0984f5a`; 53 unit tests and Playwright 6/6. Token 47 (`orgchain-tapkey-20261015`, `write:repository`) did the pushes and is deleted right after; the table is checked. Why: Orgchain showed lineage's keys only as far as the npub, and the operator wants agents with a key that holds and signs on chain.
 - 2026-10-15 · **Taproot and SegWit for every lineage account, listed rather than derived.** The operator asked for Taproot in its own right (it is where inscriptions live, and no one should have to derive it from an npub) and for agents' other public Bitcoin addresses. Every account of an org's seed now has standard addresses at the same index as its NIP-06 key: BIP-86 Taproot for inscriptions and BIP-84 SegWit for payments (0 is the org, whose SegWit branch is its treasury; agents are 1..n). The lineage key tree page derives them on mainnet paths, adds the org's Taproot beside its treasury, and lists agents' addresses in their keyrings and in `lineage.json`; the org rows check against the BIP-84 and BIP-86 vectors, and agent addresses were cross-checked against tapscript. Orgchain v1.3 holds every node's inscription at its BIP-86 Taproot key on test paths (`m/86'/1'/…`) and shows Taproot, SegWit and npub with their paths. v1.2's tapkey (the npub's key with the BIP-86 tweak) is retired; labs keyed by v1.1 or v1.2 keep their keys until reset. Proposed for spec v0.1 in `docs/lineage.md`. `lineage/orgchain` main `0af51dc`, time's `gh-pages` `7e08cc5`; 54 unit tests and Playwright 6/6. Token 49 (`lineage-btc-20261015`, `write:repository`) did the pushes and is deleted right after; the table is checked. Why: inscriptions live at Taproot addresses, and an agent's addresses belong in what it publishes.
 - 2026-10-15 · **Prod runs Gitea 28.0.0, and its Fly config lives in this repo.** Prod went up on the floating `docker.gitea.com/gitea:1.24` tag (1.24.7) while the shell on hb-5 already ran 28.0.0, so the move off the old factory had gone backwards. At the operator's word prod now runs 28.0.0. First a rehearsal: a copy of prod's data (a sqlite backup plus the repos) ran under 28.0.0 in Docker on hb-5, migrations 321 to 355 went through in two seconds, and the Tea MCP's smoke test passed against it; the copy was deleted afterwards. Then Fly snapshot `vs_M9PaLKQVDwX0hZXq1q2MO` of `gitea_data` (5-day retention) and an on-volume copy, `/data/gitea/gitea.db.pre28-20261015`, before the deploy at 02:44 UTC. A migrated database won't start on 1.24, so going back means restoring one of those. Checked afterwards: version and health, the web UI and its GitHub sign-in, the Claude connector (still signed in), a smoke run on `fly-iad-1`, Time's next scheduled tick, a pages hook delivery, Phast and Boring. green-tea's `fly.toml` had lived only in hb-5 `~/green-tea`; it is now `gitea/fly.toml` here, pinned to the exact release, and the hb-5 copy is renamed beside a pointer. What 28 changes for us: workflows' `permissions:` blocks are enforced now (Time's ask for what they use; heartbeat and astra have none, and the default still lets the job token comment, checked in a throwaway repo that is deleted), `concurrency:` groups are honoured, finished runs are deleted after 400 days, webhooks go out under 28's egress rules (the pages hooks are public https, which they allow), and the run and job API exists. So Tea MCP 2.1 (`40706b8`) lists runs in `tea_actions` and reads job logs with `tea_action_logs`; `boring_teahub_deploy` shipped it. The steward's token routine (CLI mint, sqlite delete) works unchanged. Token 48 (`gitea28-20261015`, `write:repository`) pushed 2.1 and this line and is deleted by id right after; the table is checked. Why: the operator said the migration off the old factory had regressed Gitea and asked for 28.
+- 2026-10-15 · **The tapkey stays beside Taproot, and Orgchain shows every secret.** The operator likes the npub ↔ tapkey link (Nosft's model, from the Deezy thread) and wants Orgchain to be the full platform for running lineage LLCs, with secrets shown as on the key tree page. Both pages now list each npub's tapkey (its nostr key with the BIP-86 tweak) beside the Taproot and SegWit accounts, and the key tree page's keyring and `lineage.json` carry it. A node's inscription stays at its standard BIP-86 key: the tapkey is where anyone can send to an npub, while the key that carries an org's authority is not one that nostr clients hold. Orgchain v1.4 adds a Reveal panel to every node (the seed for holdings and orgs, the nsec, Taproot, SegWit and Tapkey descriptors with test-network WIF and BIP-380 checksums, and the leaves' private keys), hidden again on every selection. Its output matches the key tree page byte for byte (the tests pin hashes of the page's own output), BIP-84's WIF vector and BIP-380's checksum vector, and `ssh-keygen` reads its OpenSSH keys. The key tree page's descriptors gain checksums too. `lineage/orgchain` main `17b8692`, time's `gh-pages` `d481ba9`; 56 unit tests and Playwright 6/6. Token 50 (`lineage-secrets-20261015`, `write:repository`) did the pushes and is deleted right after; the table is checked. Why: Orgchain is meant to run the LLCs, not only draw them, and an npub should reach the chain on its own.