diff --git a/.planning/REQUIREMENTS.md b/.planning/REQUIREMENTS.md index dc40e984..ebd188a0 100644 --- a/.planning/REQUIREMENTS.md +++ b/.planning/REQUIREMENTS.md @@ -17,6 +17,7 @@ declared exit criteria (multinode pass + workstreams B/C/F), `.planning/codebase - [ ] **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 +- [ ] **FED-06**: On-brand payment success animation — the invoice "paid" tick's circle uses the screensaver-style ring with outer EQ-segment lines (reuse `ScreensaverRing.vue`'s compact size) in place of the current success burst, applied consistently everywhere the paid tick shows ### UI Performance (PERF) @@ -98,6 +99,7 @@ Which phases cover which requirements. Updated during roadmap creation. | FED-03 | Phase 1 | Pending | | FED-04 | Phase 1 | Pending | | FED-05 | Phase 1 | Pending | +| FED-06 | Phase 1 | Pending | | PERF-01 | Phase 2 | Pending | | PERF-02 | Phase 2 | Pending | | PERF-03 | Phase 2 | Pending | @@ -123,8 +125,8 @@ Which phases cover which requirements. Updated during roadmap creation. | MKT-04 | Phase 8 | Pending | **Coverage:** -- v1 requirements: 28 total -- Mapped to phases: 28 +- v1 requirements: 29 total +- Mapped to phases: 29 - Unmapped: 0 --- diff --git a/.planning/ROADMAP.md b/.planning/ROADMAP.md index f7a5a2a2..da470f96 100644 --- a/.planning/ROADMAP.md +++ b/.planning/ROADMAP.md @@ -32,13 +32,14 @@ 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, FED-05 +**Requirements**: FED-01, FED-02, FED-03, FED-04, FED-05, FED-06 **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 + 6. The invoice/payment "paid" success animation is on-brand: the tick's circle is the screensaver-style ring with the outer EQ-segment lines (reuse `neode-ui/src/components/ScreensaverRing.vue`, which already ships a `compact` overlay size), replacing the current burst in the payment success pane (`neode-ui/src/components/SendBitcoinModal.vue`) and matching wherever else the paid tick appears **Plans**: TBD **UI hint**: yes diff --git a/.planning/STATE.md b/.planning/STATE.md index f4e3b406..8414023b 100644 --- a/.planning/STATE.md +++ b/.planning/STATE.md @@ -47,6 +47,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 +- FED-06 added to Phase 1 (2026-07-29): on-brand paid-tick animation — screensaver ring + EQ segments (reuse ScreensaverRing.vue compact) replacing the success burst in SendBitcoinModal.vue ### Decisions