From 8c2a55eb4c7eccb7beb77e0346fcfa26865ded09 Mon Sep 17 00:00:00 2001 From: archipelago Date: Wed, 29 Jul 2026 10:59:48 -0400 Subject: [PATCH] docs: add FED-05 inter-node lightning channel-open UX to Phase 1 --- .planning/REQUIREMENTS.md | 6 ++++-- .planning/ROADMAP.md | 4 +++- .planning/STATE.md | 1 + 3 files changed, 8 insertions(+), 3 deletions(-) diff --git a/.planning/REQUIREMENTS.md b/.planning/REQUIREMENTS.md index 8b61fc73..dc40e984 100644 --- a/.planning/REQUIREMENTS.md +++ b/.planning/REQUIREMENTS.md @@ -16,6 +16,7 @@ declared exit criteria (multinode pass + workstreams B/C/F), `.planning/codebase - [ ] **FED-02**: Federation sync converges and is observable — after sync settles, fleet nodes agree on the node list with fresh status; stale entries, duplicates, and silent sync failures are eliminated and sync errors are operator-visible - [ ] **FED-03**: A structured code review of the federation/fleet area (`core/archipelago/src/federation`, node sync, FIPS/transport dial layer) and mesh area (`core/archipelago/src/mesh`, mesh RPC surface) is completed, with every finding fixed or explicitly deferred with a reason - [ ] **FED-04**: Mesh messaging parity — attachment send (and the rest of the mesh chat surface) behaves identically on the demo and on real nodes: the demo backend implements the same RPC surface the UI calls, transport decisions mirror the real size-based tier logic, and no demo-only modals exist +- [ ] **FED-05**: Inter-node Lightning channel opening UX — the UI shows the node's shareable Lightning URI; lists trusted (federated) nodes by hostname for one-click channel opening; and lets the user browse/request channels with public nodes — using the existing design system and components, verified on the :8100 dev preview against archi-dev before deploy ### UI Performance (PERF) @@ -96,6 +97,7 @@ Which phases cover which requirements. Updated during roadmap creation. | FED-02 | Phase 1 | Pending | | FED-03 | Phase 1 | Pending | | FED-04 | Phase 1 | Pending | +| FED-05 | Phase 1 | Pending | | PERF-01 | Phase 2 | Pending | | PERF-02 | Phase 2 | Pending | | PERF-03 | Phase 2 | Pending | @@ -121,8 +123,8 @@ Which phases cover which requirements. Updated during roadmap creation. | MKT-04 | Phase 8 | Pending | **Coverage:** -- v1 requirements: 27 total -- Mapped to phases: 27 +- v1 requirements: 28 total +- Mapped to phases: 28 - Unmapped: 0 --- diff --git a/.planning/ROADMAP.md b/.planning/ROADMAP.md index 8e0d334b..f7a5a2a2 100644 --- a/.planning/ROADMAP.md +++ b/.planning/ROADMAP.md @@ -32,13 +32,15 @@ signed/decentralized registry and a user installs it on their node. ### Phase 1: Federation & Mesh Hardening **Goal**: Federation and mesh are tight — a structured review of the fleet/federation and mesh code feeds fixes so node removal sticks, sync converges, and mesh messaging (including attachments) behaves identically everywhere it runs **Depends on**: Nothing (first phase) -**Requirements**: FED-01, FED-02, FED-03, FED-04 +**Requirements**: FED-01, FED-02, FED-03, FED-04, FED-05 **Success Criteria** (what must be TRUE): 1. A structured code review of the federation/fleet area (`core/archipelago/src/federation`, node sync, FIPS/transport dial layer) and the mesh area (`core/archipelago/src/mesh`, mesh RPC surface) produces a findings list, and every finding is fixed or explicitly deferred with a reason 2. Removing a federation node removes it everywhere — it disappears from all UI surfaces, tombstones propagate, and it never reappears after later sync cycles; a failed removal surfaces an error instead of silently no-opping 3. Federation sync converges: after sync settles, fleet nodes agree on the node list and node status is fresh — stale entries, duplicates, and silent sync failures are gone, and sync errors are visible to the operator 4. Mesh attachment send works identically on the demo and on real nodes — same modals, same transport decisions, same success — with the demo backend implementing the same RPC surface the UI calls (no "Method not found", no demo-only chooser modal) + 5. Channel-opening between nodes is first-class UI: a user can copy/share their node's Lightning URI; sees a list of trusted (federated) nodes by hostname to open a channel with in one flow; and can browse/request channels with public nodes — built with the existing design system (Teleport-to-body modals, house style), tested live on the :8100 dev preview against archi-dev, and fixed there before any deploy **Plans**: TBD +**UI hint**: yes ### Phase 2: UI Performance **Goal**: The UI feels fast — switching tabs and opening secondary screens (screens reached from a tab's main page) renders promptly instead of stalling on refetches and remounts diff --git a/.planning/STATE.md b/.planning/STATE.md index f1705a0c..f4e3b406 100644 --- a/.planning/STATE.md +++ b/.planning/STATE.md @@ -46,6 +46,7 @@ Progress: [░░░░░░░░░░] 0% - Phase 1 added (2026-07-29): Federation & Mesh Hardening — user-directed top priority (node removal/sync issues, mesh attachment parity incl. demo); prior phases shifted down - Phase 2 added (2026-07-29): UI Performance — slow tab switches and secondary screens; prior phases shifted down +- FED-05 added to Phase 1 (2026-07-29): inter-node Lightning channel-opening UX (share node URI, pick trusted/federated nodes by hostname, request channels with public nodes); UI tested on :8100 dev preview against archi-dev before deploy ### Decisions