decisions + lineage: Orgchain v1.2 (tapkeys and lineage's leaves)

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

docs/decisions.md

@@ -52,3 +52,4 @@ Format: date · decision · why. Add at the bottom. Never edit an old entry; sup
 - 2026-10-15 · **Orgchain v1 is lineage's app, in lineage's own org.** Super Testnet's kitchen sink becomes the UI for creating and operating lineage holdings: holdings, a tree drawn like docs/lineage.md, and six verbs (found, birth, award, decide, graduate, close), each a `lineage/v0` inscription whose parent is the node that authorizes it. One reducer folds the events into trees and vets every act before it is signed. Super Testnet's auto-miner is now Time: a tempo (each act, 10/30/60 s, or manual), Beat now, and a slider that replays any holding beat by beat. New org `lineage`, repo `lineage/orgchain` (main `6acc319`, Super Testnet's history kept, its engine unchanged). A parallel session's tree work (lab keys, act as any node, graduation by claim + countersign; `2ea7884`, never deployed, paused at the operator's word) is kept there as branch `tree`, to be compared and folded in. The build replaces `ventures/lineage/orgchain/` on time's `gh-pages`, and `/orgchain/*` gets a stricter CSP (`connect-src 'none'`, no frames; the app makes no requests). 43 unit tests; Playwright at desktop and phone sizes through every verb, the clock and replay, also against pages with the real headers. Token 44 (`orgchain-v1-20261015`, `write:repository`) did the pushes and is deleted right after; the table is checked. Why: the operator wanted Orgchain simpler and shaped to lineage (lineage gives the structure, Orgchain adds actions across time), lineage in its own org, and the auto-miner as Time.
 - 2026-10-15 · **Tea MCP 2.0: typed tools, pull requests, commits and Actions settings, all as the caller.** `mcp/tea_mcp/server.py` is rewritten (`fb8acb0`, then `fbb1159`): still one file, still acting only with the caller's own Gitea token, now 29 tools. Parameters are typed (patterns, ranges, enums), so a bad argument is refused before Gitea is asked and every limit shows in the tool's schema. New: `tea_pull_get/create/review/merge` (merge keeps the head branch), `tea_labels`, `tea_label`, `tea_commit` (up to 50 files, text or base64), `tea_branch_create`, `tea_repo_edit` (archive included), `tea_hook_create` (one hook per URL), `tea_secret_set` and `tea_variable_set`. Fixed: unknown labels are refused; create or update comes from looking the file up, not from "404" in an error message; org repositories are private by default like user ones; `tea_org_add_member` names its team; `more` and `truncated` come from Gitea's totals; comments page correctly. `tea_actions` had never worked, because Gitea 1.24 has no `/actions/runs`; it reads `/actions/tasks` now. 1.24 has no API that lists a run's jobs either, so there is no log tool yet. The Gitea on hb-5 (28.0.0) has that API, so upgrading prod's Gitea would bring it. 27 tests run against a fake Gitea, and every tool ran once against teahub.xyz in a scratch repo and org, both deleted after. Connectors that still hold 1.0's tool list keep working (2.0.1 also takes `labels` as a string). The old Tea MCP container on hb-5 (`teahub-mcp`, with its Phast sidecar), idle since the cutover, is stopped and set not to restart; it and its volume are kept. Boring's `boring_teahub_*` now operate `green-tea-mcp` (matcha/boring `122f0b3`, shipped by its own deploy workflow). `boring_teahub_deploy` shipped 2.0.1 from the exact main SHA, and status reads that SHA back from the image tag (`fresh: true`). Codex on hb-5 lists `tea` and `boring` as not logged in; `codex mcp login tea` signs it in. Token 43 (`tea-mcp-smoke-20261015`) ran the smoke test and the first push and was deleted by id (the API now answers 401 to it); token 45 (`tea-mcp-201-20261015`) pushed 2.0.1 and this line and is deleted by id right after. Both were `teahubxyz`'s, neither was printed, and the table is checked. Why: #9's audit and plan.
 - 2026-10-15 · **Orgchain v1.1: lineage's keys, merged from the tree branch.** The parallel session's key layer (`tree`, `2ea7884`) folds into v1: its `lineage-keys.js` and `handoff.js` come over as written, with their BIP-85, BIP-86 and NIP-06 spec vectors; its off-chain keyring and old UI stay behind, because v1's tree comes from the chain. Each holding gets its own 24-word lab root; every node holds its inscription at its lineage key (BIP-85 org seeds, agents as accounts 1..n of their org's seed, BIP-86 wallets, NIP-06 npubs); every act is signed by whichever key holds the authorizing inscription; graduation is a claim by the org's fresh root countersigned by its derived key, and the derived subtree re-keys under the new root, so the parent's line can no longer sign for it. Labs saved before keys still load and sign with the lab wallet. `lineage/orgchain` main `744c594`; 49 unit tests and Playwright 6/6, keys included. Token 46 (`orgchain-keys-20261015`, `write:repository`) did the pushes and is deleted right after; the table is checked. Why: the operator made this session the lead and asked for the two to be compared and whatever helped used; the tree was the half v1 had left for later, enforcement.
+- 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.

docs/lineage.md

@@ -25,9 +25,11 @@ app ([`lineage/orgchain`](https://teahub.xyz/lineage/orgchain)). Found a holding
 belts, record decisions, graduate and close. Each act is a `lineage/v0` inscription whose parent is the node that
 authorizes it, on a private toy chain in the browser with pretend money. Time is a tempo (each act its own beat, or acts
 cued and landed together every 10, 30 or 60 s, or by hand), and a slider replays any holding beat by beat. Every
-node holds its inscription at its own lineage key (a lab root per holding, BIP-85 org seeds, seats as accounts), each
+node holds its inscription at its tapkey, which is its npub with the BIP-86 tweak (a lab root per holding, BIP-85 org
-act is signed by whichever key holds the authorizing inscription, and graduation is a claim by the org's fresh root,
+seeds, seats as accounts), and shows its leaves as [the key tree](https://lineage.yolopreneur.lol/) derives them: ssh,
-countersigned by its derived key, with the derived subtree re-keying under it. Closing is still a recorded event.
+git, dkim and wg for agents; ssh-ca, mtls and noise for orgs. Each act is signed by whichever key holds the authorizing
+inscription, and graduation is a claim by the org's fresh root, countersigned by its derived key, with the derived
+subtree re-keying under it. Closing is still a recorded event.
 
 ## Rules
 1. **One template, every depth.** An org is legal key · treasury · identity · agents · orgs. The factory's own org and