decisions: Orgchain layout fix

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

docs/decisions.md

@@ -56,3 +56,4 @@ Format: date · decision · why. Add at the bottom. Never edit an old entry; sup
 - 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.
+- 2026-10-15 · **Orgchain layout: three columns, no gap above the timeline.** The operator's screenshot showed the timeline far below the tree: the act and inspect column, now long with keys, leaves and secrets, spanned both grid rows and stretched the first. Orgchain is now three columns that run on their own (holdings; the tree with its timeline; act and inspect) over a flexible last row, and the medium layout keeps the timeline under the tree too; checked at 1440, 1280, 1100, 900 and 390 px. The footer links the scure licenses. `lineage/orgchain` main `aeb11d3`, time's `gh-pages` `0b0f27a`; 56 unit tests and Playwright 6/6. Token 51 (`orgchain-layout-20261015`, `write:repository`) did the pushes and is deleted right after; the table is checked. Why: the operator asked for the formatting to be fixed.