lineage: Orgchain v1.1 has lineage's keys; decisions receipt

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

docs/decisions.md

@@ -51,3 +51,4 @@ Format: date · decision · why. Add at the bottom. Never edit an old entry; sup
 - 2026-10-15 · **hb-5 is the shell of the old factory, and Boring can show pictures.** The operator's framing: the hb-5 Gitea is the shell of the old factory, where their maths and other experiments live. It isn't a second factory to migrate, and Boring, the operator's admin lane, stays there. So the rule sits at the door: a project that graduates to prod moves with its history, and the copy left in the shell is archived with a pointer. phast, persims, phly, supertestnet, inscriboor and notplanned now carry that sign; persimmons was already archived. Boring's instructions and AGENTS.md, and the shell's matcha/teahub AGENTS.md and docs/self-map.md, now describe this layout. Boring has two new tools that return MCP images instead of text: `boring_mac_screenshot` (Peekaboo; the whole screen or one app's window) and `boring_mac_view_image` (an image under ~/claude/shots or /tmp). They were deployed by matcha/boring's own `deploy-boring-runtime` workflow (source 8742f9c; verification passed, no rollback). That workflow's clone URL had to move from https://teahub.xyz/matcha/boring.git, which is prod now, to the shell at 192.168.5.2:3000. Found on the way: macminid's `use_vision` snapshot hangs and wedges the daemon (restarted twice; avoid it), and matcha/boring `board-tick` has failed every 5 minutes since the move because it reads the old board through https://teahub.xyz (401 on prod). Token 42 (`shell-20261015`) pushed this and is deleted by id right after; the table is checked. Why: the earlier regression came from a second copy with no sign, and an agent that can't see a page can't check it.
 - 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.