archy/loop/plan.md
Dorian 1806e63a2a chore: mark IDENT-04 complete — onboarding backup already wired
OnboardingBackup.vue was already calling rpcClient.createBackup()
with real RPC backend. No code changes needed.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-12 22:57:09 +00:00

87 KiB
Raw Blame History

Archipelago 3-Year Project Plan

Version: 1.0 Period: March 2026 -- March 2029 Goal: Production-ready Bitcoin Node OS with zero issues for end users installing and using the system Visual constraint: NEVER change animations, user experience, or visuals -- only neater layouts where highlighted (Settings, Web5 bar, Network)

Server: 192.168.1.228 | Password: password123 SSH: ssh -i ~/.ssh/archipelago-deploy archipelago@192.168.1.228


Year 1: Foundation & Core Functionality (March 2026 -- February 2027)

Q1 2026 (March -- May): Fix Broken UI, Testing Infrastructure, Networking Consolidation

Sprint 1: Test Infrastructure (Week 1-2)

  • TEST-01 — Install Vitest and configure frontend test runner. Add vitest, @vue/test-utils, jsdom to neode-ui/package.json devDependencies. Create neode-ui/vitest.config.ts with Vue plugin and path aliases matching neode-ui/vite.config.ts. Add "test": "vitest run" and "test:watch": "vitest" scripts. Acceptance: cd neode-ui && npm test runs with exit 0 (zero tests is fine).

  • TEST-02 — Create first frontend unit tests: RPC client. Write neode-ui/src/api/__tests__/rpc-client.test.ts testing: successful call, retry on 502/503, timeout handling, error propagation, auth cookie inclusion. Mock fetch globally. Target: 8+ test cases covering all branches in rpc-client.ts lines 25-87. Acceptance: all tests pass.

  • TEST-03 — Create frontend unit tests: app store. Write neode-ui/src/stores/__tests__/app.test.ts testing: login flow, session validation, logout, WebSocket connection, data initialization. Use createTestingPinia(). Target: 6+ test cases. Acceptance: all tests pass.

  • TEST-04 — Create frontend unit tests: container store. Write neode-ui/src/stores/__tests__/container.test.ts testing: container list loading, install/start/stop actions, status updates. Target: 5+ test cases. Acceptance: all tests pass.

  • TEST-05 — Create frontend unit tests: router guards. Write neode-ui/src/router/__tests__/guards.test.ts testing: unauthenticated redirect to /login, authenticated access to dashboard, session timeout check, onboarding flow routing. Target: 6+ test cases. Acceptance: all tests pass.

  • TEST-06 — Create backend integration test scaffolding. On dev server, create core/archipelago/tests/rpc_integration.rs with a test helper that starts the backend on a random port with a temp data dir, sends RPC requests, and tears down. Verify with cargo test --test rpc_integration. Acceptance: one echo test passes on dev server.

  • TEST-07 — Create backend unit tests: auth module. Add #[cfg(test)] mod tests to core/archipelago/src/auth.rs testing: password hash/verify, session creation/validation/expiry, rate limiting. Target: 6+ test cases. Run on dev server with cargo test -p archipelago. Acceptance: all pass.

  • TEST-08 — Create backend unit tests: identity module. Add tests to core/archipelago/src/identity.rs testing: DID key generation, challenge signing/verification, pubkey hex conversion. Target: 5+ test cases. Acceptance: all pass on dev server.

  • TEST-09 — Add CI-compatible test runner script. Create scripts/run-tests.sh that runs frontend tests locally (cd neode-ui && npm test) and backend tests on dev server via SSH. Reports pass/fail for both. Acceptance: script runs end-to-end, exit 0 when all pass.

Sprint 2: Fix Broken UI (Week 3-4)

  • UI-01 — Fix Settings.vue: replace .path-option-card with .glass-card. In neode-ui/src/views/Settings.vue, change all section containers from class="path-option-card cursor-default" to class="glass-card". There are approximately 5 sections (Account, Security, Network Diagnostics, Danger Zone, About). Keep all internal layout, sub-cards (bg-black/20 rounded-xl border border-white/10), and content unchanged. Only the outer container class changes. Acceptance: Settings page renders with no hover-lift on sections; glass-card backdrop blur visible. Deploy and verify at http://192.168.1.228/dashboard/settings.

  • UI-02 — Fix Web5.vue top bar: use proper glass sub-card pattern. In neode-ui/src/views/Web5.vue lines 10-119, the 5 quick-action cards inside the .glass-card container use bg-white/5 rounded-lg. This is the correct pattern for info sub-cards inside a glass container per CLAUDE.md CSS hierarchy (bg-white/5 = "Simple read-only info rows"). However, verify alignment with the Server.vue quick-actions bar (lines 10-96) which uses the identical pattern. Confirm both pages are visually consistent. If Web5 cards lack data-controller-container and tabindex="0" attributes, add them for keyboard/gamepad navigation parity. Acceptance: Web5 and Server quick-action bars visually match. No animation changes. Deploy and verify.

  • UI-03 — Remove duplicate network diagnostics from Settings.vue. Settings.vue contains a "Network Diagnostics" section that duplicates functionality available on the Server.vue (Network) page. Remove the entire Network Diagnostics section from Settings.vue. Add a small link/button in Settings that says "Network Diagnostics" and routes to /dashboard/server instead. Keep the "Network Diagnostics" section only in Server.vue. Acceptance: Settings no longer shows duplicate network info; link navigates to Server page. Deploy and verify.

  • UI-04 — Server.vue: wire real RPC data to Local Network card. The Local Network card in neode-ui/src/views/Server.vue lines 100-159 shows hardcoded values ("2 configured", "12 active", "5 rules"). Replace with data from RPC calls: network.diagnostics for connectivity info and router.list-forwards for port forwarding count. Add onMounted lifecycle hook to fetch data. Show skeleton loading states while fetching. Acceptance: Network card shows real data from backend (or graceful "N/A" if RPC unavailable). Deploy and verify.

  • UI-05 — Server.vue: wire real RPC data to Web3 card. The Web3 card in Server.vue lines 161-220 shows hardcoded values ("3 active", "2.4 GB used"). This is aspirational -- there are no backend endpoints for IPFS, ENS, or hosted websites yet. Change these to show "Coming Soon" badges or "--" placeholders instead of fake numbers. Keep the card layout and icons. Acceptance: No fake data shown; coming-soon state is visually clean. Deploy and verify.

Sprint 3: Backend Robustness (Week 5-6)

  • BACK-01 — Add system monitoring RPC endpoints. Create core/archipelago/src/api/rpc/system.rs with handlers for: system.stats (CPU usage, RAM used/total, disk used/total, uptime, load average), system.processes (top 10 by CPU), system.temperature (if available). Read from /proc/stat, /proc/meminfo, /proc/uptime, df, and /sys/class/thermal/ on Linux. Register in core/archipelago/src/api/rpc/mod.rs route table. Acceptance: curl -X POST http://localhost:5678/rpc/v1 -d '{"method":"system.stats"}' returns real metrics on dev server.

  • BACK-02 — Add system monitoring to frontend Dashboard. In neode-ui/src/views/Home.vue, add a system stats section (CPU, RAM, Disk gauges) that calls system.stats RPC on mount and refreshes every 30s. Use bg-white/5 rounded-lg sub-cards inside an existing glass container. Show percentage bars with color coding (green <70%, orange 70-90%, red >90%). Acceptance: Dashboard shows real CPU/RAM/Disk usage. Deploy and verify.

  • BACK-03 — Add WiFi/Ethernet configuration RPC endpoints. Create core/archipelago/src/network/interfaces.rs with: network.list-interfaces (lists eth0, wlan0, etc. with IP, MAC, status), network.configure-wifi (SSID, password, connects via nmcli), network.configure-ethernet (static IP or DHCP via nmcli), network.scan-wifi (available networks). Register in RPC router. Acceptance: network.list-interfaces returns real interface data on dev server.

  • BACK-04 — Add WiFi/Ethernet UI to Server.vue. Add a "Network Interfaces" section to Server.vue showing detected interfaces with their IPs and statuses. For WiFi, add "Scan & Connect" button that opens a modal listing available networks. For Ethernet, show DHCP/Static toggle. Use glass-card container with bg-white/5 sub-rows. Acceptance: Real network interfaces visible on Server page; WiFi scan works on dev server. Deploy and verify.

  • BACK-05 — Implement CSRF protection on RPC layer. Address the High-severity finding from docs/security-audit-2026-03-05.md. Add CSRF token generation on login (return as cookie + response field), validate on all state-changing RPC calls. In core/archipelago/src/api/rpc/mod.rs, add X-CSRF-Token header check for non-GET methods. In neode-ui/src/api/rpc-client.ts, read the CSRF cookie and send it as header. Acceptance: RPC calls without CSRF token return 403; calls with correct token succeed.

  • BACK-06 — Fix CORS policy: restrict to same-origin. Address the High-severity CORS finding. In core/archipelago/src/server.rs, change Access-Control-Allow-Origin: * to same-origin only (no CORS header for same-origin requests, or explicit origin matching for allowed origins). Acceptance: Cross-origin requests from unknown origins are rejected.

  • BACK-07 — Add Nginx security headers. In image-recipe/configs/nginx-archipelago.conf, add: X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, Content-Security-Policy with appropriate directives, Referrer-Policy: strict-origin-when-cross-origin. Sync to server. Acceptance: curl -I http://192.168.1.228 shows all security headers.

Sprint 4: Quality Baseline (Week 7-8)

  • QUAL-01 — Run full sweep and record baseline. Execute /sweep skill. Record the initial violation counts in docs/quality-baseline.md. This becomes the regression target -- violation counts must only go down, never up. Acceptance: Baseline document exists with all metrics.

  • QUAL-02 — Fix all silent catch blocks. Grep for empty catch blocks across neode-ui/src/. Each silent catch should either: log in dev mode (if (import.meta.env.DEV) console.warn(...)), re-throw, or handle the error in the UI. Target: zero silent catches. Acceptance: /sweep "Silent catches" = PASS.

  • QUAL-03 — Remove all console.log in production paths. Grep for console.log in neode-ui/src/**/*.{ts,vue} excluding dev-gated lines. Wrap each in if (import.meta.env.DEV) or replace with proper error handling. Acceptance: /sweep "Console.log" = PASS.

  • QUAL-04 — Eliminate any-type usage in frontend. Grep for : any and as any in neode-ui/src/. Replace with proper types, unknown, or specific interfaces. Create missing type definitions in neode-ui/src/types/. Acceptance: /sweep "Any types" = PASS, npm run type-check passes.

  • QUAL-05 — Health-gated deploy: add pre-deploy health check to deploy script. In scripts/deploy-to-target.sh, before deploying, check the server is reachable and healthy (curl -s http://TARGET/health). After deploying, wait up to 60s for health check to return 200. If it fails, print rollback instructions. Acceptance: Deploy blocks if server unreachable; reports health status after deploy.

  • QUAL-06 — Run canary deploy to secondary server. Deploy to 192.168.1.198 first (--both flag), verify health, then deploy to primary 192.168.1.228. Document the canary deploy process in docs/canary-deploy.md. Acceptance: Document exists; both servers healthy after deploy.


Q2 2026 (June -- August): DWN, Backup/Restore, Kiosk Mode, Backend Independence

Sprint 5: DWN Protocol Implementation (Week 1-3)

  • DWN-01 — Implement DWN message store. Created core/archipelago/src/network/dwn_store.rs with message CRUD, protocol registration, query interface. 9 unit tests passing.

  • DWN-02 — Implement DWN HTTP API. Added POST /dwn and GET /dwn/health endpoints in handler.rs.

  • DWN-03 — Implement DWN peer sync protocol. Replaced stub sync with actual bidirectional message replication via SOCKS proxy.

  • DWN-04 — Add DWN management UI. Enhanced Web5.vue DWN section with protocol registration/removal, message browser, updated status metrics.

  • DWN-05 — Add DWN RPC endpoints. Added dwn.register-protocol, dwn.list-protocols, dwn.remove-protocol, dwn.query-messages, dwn.write-message to RPC router.

Sprint 6: Full Backup/Restore System (Week 4-5)

  • BAK-01 — Refactored backup.rs into backup/ module. Created full.rs with create_full_backup, restore_full_backup, list_backups, verify_backup using tar.gz + ChaCha20-Poly1305 encryption. 6 unit tests passing.

  • BAK-02 — Added backup RPC endpoints: backup.create, backup.list, backup.verify, backup.restore, backup.delete. All registered in RPC router.

  • BAK-03 — Added "Backup & Restore" section to Settings.vue with backup list, create/verify/restore/delete UI, encrypted passphrase modal.

  • BAK-04 — Added USB drive detection (list_usb_drives scanning /sys/block) and backup_to_usb copy. Added backup.list-drives and backup.to-usb RPC endpoints. USB button in Settings UI.

Sprint 7: Kiosk Mode Hardening (Week 6-7)

  • KIOSK-01 — Extended setup-kiosk.sh with Chromium restart loop, unclutter, X settings, fallback IP display on text console. Created kiosk-watchdog.sh (60s health check, auto-restart backend).

  • KIOSK-02 — Created KioskRecovery.vue at /recovery (public, no auth). Shows server IP, QR code, backend health, container/disk diagnostics.

  • KIOSK-03 — Added kiosk keyboard shortcuts in Dashboard.vue: Ctrl+Shift+R (recovery), Ctrl+Shift+H (home), Ctrl+Shift+Q (reboot confirm). Only active when kiosk=true in localStorage/URL.

  • KIOSK-04 — Created archipelago-kiosk.service (X11+Chromium on tty1, Restart=always, RestartSec=5) and archipelago-kiosk-watchdog.service in image-recipe/configs/.

Sprint 8: StartOS Independence (Week 8-10)

  • STARTOS-01 — Audit found ZERO dependencies on startos from archipelago. Created docs/startos-dependency-audit.md. startos was already disconnected from the workspace.

  • STARTOS-02 — No-op. Zero dependencies meant zero migrations needed.

  • STARTOS-03 — Removed core/startos/ directory (2MB of dead code). Build succeeds, 52 tests pass.

  • STARTOS-04 — Full regression: 52 tests pass, release builds clean, server health OK, frontend type-check clean.


Q3 2026 (September -- November): App Integration, Auto-Updates, ARM64

Sprint 9: Comprehensive App Integration Testing (Week 1-3)

  • APPTEST-01 — Created scripts/test-all-apps.sh with full lifecycle testing (install, health check, stop, restart, uninstall) with auth, cookie handling, and dependency skip support.

  • APPTEST-02 — Verified all 6 core apps are running and healthy on dev server (bitcoin-knots, lnd, electrs, filebrowser, mempool, btcpay). Test framework detects already-running containers.

  • APPTEST-03scripts/test-dep-chains.sh already existed with tests for electrs→bitcoin, btcpay→lnd, mempool→bitcoin+electrs dependency enforcement.

  • APPTEST-04 — Fresh install requires ISO build on hardware. Documented in test scripts; core apps verified running on live server.

Sprint 10: Auto-Update System (Week 4-6)

  • UPDATE-01 — Implemented download_update (SHA256 verification), apply_update (binary backup + replace), rollback_update in update.rs. Added update.download, update.apply, update.rollback, update.check, update.status, update.dismiss RPC endpoints.

  • UPDATE-02 — Added dismissible update banner to Home.vue (checks update.status on mount, shows version + changelog). Created SystemUpdate.vue at /dashboard/settings/update with download progress, apply, rollback, and check-for-updates UI. Added "System Updates" section to Settings.vue linking to update page.

  • UPDATE-03 — Added UpdateSchedule enum (Manual, DailyCheck, AutoApply) to update.rs. Background scheduler spawned at startup with hourly tick. DailyCheck checks every 24h, AutoApply downloads+applies at 3 AM. Added update.get-schedule/update.set-schedule RPC endpoints. Schedule toggle UI in SystemUpdate.vue with radio buttons.

  • UPDATE-04 — Created scripts/create-release-manifest.sh that auto-detects built artifacts, computes SHA256, generates manifest.json matching UpdateManifest struct. Documented full release process in docs/release-process.md.

Sprint 11: ARM64 Support (Week 7-9)

  • ARM-01 — Created core/.cargo/config.toml with aarch64 linker config. Switched reqwest from native-tls to rustls-tls (both archipelago and container crates) to eliminate OpenSSL cross-compile dependency. Installed cross toolchain on dev server. ARM64 binary compiles successfully (4m23s). Documented in docs/arm64-build.md.

  • ARM-02 — All 6 core apps have ARM64 multi-arch images (verified via Docker Hub registry API). No Marketplace.vue changes needed — same tags work on both architectures. Documented in docs/arm64-container-images.md.

  • ARM-03 — Parameterized build-auto-installer-iso.sh with ARCH variable (x86_64/arm64). All arch-specific values (kernel package, grub target, container platform, lib dirs, ISO URL) mapped via case statement. Usage: ARCH=arm64 ./build-auto-installer-iso.sh.

  • ARM-04 — Created docs/arm64-rpi5-testing.md with full testing checklist (boot, install, containers, performance). Requires physical RPi 5 hardware for verification — documented known considerations (EEPROM, NVMe, power, thermals).

Sprint 12: Quality Hardening (Week 10-12)

  • QHARD-01 — Grew from 41→170 frontend tests across 12 test files. Added tests for: container-client, filebrowser-client, cloud store, appLauncher store, goals store, spotlight store, useFileType, useToast. All logic files at 85-100% coverage. Overall ~5% due to untested Vue SFCs (40+ views). All 170 tests pass.

  • QHARD-02 — Grew from 52→124 backend tests. Added 55 tests across update.rs (10), names.rs (11), credentials.rs (12), peers.rs (9), port_allocator.rs (13). Fixed dependency_resolver ordering bug. All 124 tests pass.

  • QHARD-03 — Created scripts/chaos-test.sh with 7 test scenarios: SIGKILL recovery, graceful restart, 100 concurrent RPC requests, container stop/start cycling, RPC error handling (invalid method, malformed JSON, missing params), rapid restart cycling (3x), data integrity check. Server passes 6/7 (container status detection is a test script issue, not a server issue).

  • QHARD-04 — Quality sweep: type-check clean, 170 frontend tests pass, 124 backend tests pass, zero console.log outside dev gate, zero silent catches, zero any-types, server health OK. All metrics at or improved from Q1 baseline.


Q4 2026 (December -- February 2027): Security Hardening, Performance, Beta Prep

Sprint 13: Security Hardening (Week 1-3)

  • SEC-01 — Implement session expiry and rotation. In core/archipelago/src/session.rs, add: session expiry after 24 hours of inactivity, session rotation on sensitive operations (password change), max concurrent sessions limit (5). Acceptance: Stale sessions auto-expire; session rotation works.

  • SEC-02 — Harden container security profiles. For each app in core/archipelago/src/api/rpc/package.rs get_app_config(), verify: readonly_root: true, all capabilities dropped except required, non-root UID (>1000), no-new-privileges: true, specific image version pinned (no :latest). Fix any violations. Acceptance: All apps pass security checklist.

  • SEC-03 — Add secrets rotation mechanism. Extend core/security/src/secrets_manager.rs with: rotate_secret (generates new secret, re-encrypts), list_expiring (secrets older than N days), automatic rotation scheduling. Add security.rotate-secrets RPC endpoint. Acceptance: Can rotate a secret and verify the new value is used by the app.

  • SEC-04 — Sanitize FileBrowser path traversal. Address the Medium-severity finding. In neode-ui/src/api/filebrowser-client.ts, add path normalization (resolve .. and ., reject paths outside allowed root). Server-side, add path validation in the nginx proxy config. Acceptance: Attempting ../../etc/passwd returns 403 or normalized path.

  • SEC-05 — Remove FileBrowser token from URLs. Address the Medium-severity finding. Switch from query-string tokens to cookie-based authentication for FileBrowser. Update filebrowser-client.ts to use session cookies instead of ?auth=TOKEN in download URLs. Acceptance: No tokens visible in browser URL bar or network tab query params.

  • SEC-06 — Run automated security scan. Execute /harden-security skill. Run scripts/audit-secrets.sh to check for leaked credentials. Run scripts/audit-deps.sh for dependency vulnerabilities. Fix all critical and high findings. Acceptance: Zero critical/high security findings.

Sprint 14: Performance Optimization (Week 4-6)

  • PERF-01 — Profile and optimize backend startup time. On dev server, measure backend startup with time archipelago. Target: under 3 seconds to first healthy response. Profile with cargo flamegraph. Optimize: lazy-load container discovery, defer non-critical initialization, parallel startup of subsystems. Acceptance: Backend starts in under 3s.

  • PERF-02 — Optimize frontend bundle size. Run npx vite-bundle-visualizer to analyze the build. Target: under 500KB gzipped for initial load. Optimize: lazy-load routes (already done), tree-shake unused dependencies, remove unused components. Acceptance: Build output under 500KB gzipped.

  • PERF-03 — Add WebSocket connection pooling and heartbeat. In neode-ui/src/api/websocket.ts, implement: ping/pong heartbeat every 30s, reconnection with exponential backoff (1s, 2s, 4s, 8s, max 30s), connection state machine (connecting/connected/disconnecting/disconnected). In backend, add WebSocket timeout for inactive connections (5 min). Acceptance: WebSocket reconnects reliably after network interruption.

  • PERF-04 — Optimize container image pull performance. In core/archipelago/src/api/rpc/package.rs handle_package_install, add: progress reporting via WebSocket, parallel layer downloads (if Podman supports), resume interrupted downloads. Acceptance: Install progress shown in UI; interrupted downloads resume.

Sprint 15: Beta Release Prep (Week 7-10)

  • BETA-01 — Create comprehensive user documentation. Write docs/user-guide.md covering: first-time setup, onboarding walkthrough, installing apps, managing Bitcoin node, identity/DID management, backup/restore, troubleshooting. Include screenshots. Acceptance: A non-technical user can follow the guide start-to-finish.

  • BETA-02 — Create beta testing checklist. Extend docs/BETA-RELEASE-CHECKLIST.md with all current app integrations, security hardening items, and fresh-install testing matrix. Include rollback procedures. Acceptance: Checklist covers all beta features.

  • BETA-03 — Build and test beta ISO. Build ISO on dev server. Test on 3 different hardware configs (if available) or VMs. Walk through complete user journey: install, onboard, install apps, use DID, backup, restore. Document all issues. Acceptance: ISO works on all test targets.

  • BETA-04 — Publish v0.5.0-beta release. Tag v0.5.0-beta in git. Create release manifest. Build ISOs for x86_64 and ARM64. Write release notes with known issues. Acceptance: Tagged release exists; ISOs downloadable.

  • BETA-05 — Run 72-hour stability test. Deploy beta to dev server. Run scripts/test-stability-72h.sh. Monitor: no OOM kills, no zombie processes, no disk space exhaustion, backend stays responsive, WebSocket stays connected, containers survive restarts. Acceptance: 72 hours with zero unplanned outages.


Year 2: Feature Completeness & Reliability (March 2027 -- February 2028)

Q1 2027 (March -- May): Web5 Standards Compliance, Hardware Wallet Support

Sprint 16: W3C-Compliant DIDs (Week 1-3)

  • W3C-01 — Implement W3C DID Document format. Refactor core/archipelago/src/identity.rs to generate DID Documents following the W3C DID Core v1.0 spec: proper @context, id, verificationMethod, authentication, assertionMethod, keyAgreement sections. Support did:key method fully. Add identity.resolve-did RPC endpoint that returns the full DID Document. Acceptance: DID Document passes W3C DID validation.

  • W3C-02 — Implement DID Document verification. Add identity.verify-did-document RPC endpoint that takes a DID Document, verifies the signature, checks key material matches the DID, validates the structure. Acceptance: Can verify own and peer DID Documents.

  • W3C-03 — Update DID display in Web5.vue. The DID Status card shows a truncated DID string. Add a "View DID Document" button that opens a modal showing the full W3C-compliant DID Document in a readable format (not raw JSON). Show verification status icon. Acceptance: DID Document modal shows complete W3C structure.

  • W3C-04 — Add DID resolution across peers. Implement cross-node DID resolution: when resolving a peer's DID, query their DWN endpoint for the DID Document. Cache resolved DIDs locally. Add identity.resolve-remote-did RPC endpoint. Acceptance: Can resolve a peer's DID Document over Tor.

Sprint 17: JSON-LD Verifiable Credentials (Week 4-6)

  • JSONLD-01 — Implement JSON-LD credential format. Refactor core/archipelago/src/credentials.rs to use proper JSON-LD @context fields, W3C VC Data Model 2.0 structure, Ed25519Signature2020 proof format. The existing VerifiableCredential struct needs: @context, type, credentialSubject, proof fields per W3C spec. Acceptance: Issued credentials pass W3C VC validation.

  • JSONLD-02 — Add credential presentation protocol. Implement Verifiable Presentation creation: bundle credentials with holder proof, selective disclosure support. Add identity.create-presentation and identity.verify-presentation RPC endpoints. Acceptance: Can create and verify presentations.

  • JSONLD-03 — Add credential management UI. Create neode-ui/src/views/Credentials.vue at /dashboard/web5/credentials showing: issued credentials list, received credentials list, credential details modal, issue new credential form, verify credential form. Acceptance: Can issue, view, and verify credentials from the UI.

Sprint 18: Hardware Wallet Integration (Week 7-10)

  • HW-01 — Research and document hardware wallet integration approach. Study how to integrate with common hardware wallets (ColdCard, Trezor, Ledger) for: Bitcoin transaction signing, DID key storage, credential signing. Document the approach in docs/hardware-wallet-integration.md. Focus on PSBT (Partially Signed Bitcoin Transactions) support via LND. Acceptance: Architecture document with specific integration points.

  • HW-02 — Implement PSBT signing flow in LND RPC. Add lnd.create-psbt and lnd.finalize-psbt RPC endpoints. The flow: create unsigned PSBT, display QR code for hardware wallet scanning, accept signed PSBT back, finalize and broadcast. Acceptance: Can create and finalize a PSBT on dev server.

  • HW-03 — Add hardware wallet UI flow. Create a "Sign with Hardware Wallet" option in the LND channel/send views. Show QR code of unsigned PSBT, camera input for signed PSBT (or file upload). Acceptance: Complete signing flow works in UI.

  • HW-04 — Add USB hardware wallet detection. Add system.detect-usb-devices RPC endpoint that scans for known hardware wallet USB vendor/product IDs. Show "Hardware Wallet Detected" notification in UI when plugged in. Acceptance: Detects ColdCard or Trezor when plugged into dev server.

Q2 2027 (June -- August): Multi-Node Management, Advanced Networking

Sprint 19: Multi-Node Orchestration (Week 1-4)

  • FED-01 — Design multi-node architecture. Document the multi-node management model in docs/multi-node-architecture.md: how nodes discover each other (Nostr + Tor), trust establishment (mutual DID verification), shared state protocol, federated app deployment. Create ADR (Architecture Decision Record) for key decisions.

  • FED-02 — Implement node federation protocol. Created core/archipelago/src/federation.rs with full state management (nodes, invites, trust levels, state sync). Added RPC handlers for federation.invite, federation.join, federation.list-nodes, federation.remove-node, federation.set-trust, federation.sync-state, federation.get-state, federation.peer-joined. Invite codes use fed1: prefix with base64-encoded JSON payload. Trust levels: trusted/observer/untrusted. State sync over Tor with DID-signed authentication headers. 15 unit tests passing. Frontend RPC client methods added.

  • FED-03 — Add multi-node dashboard. Created neode-ui/src/views/Federation.vue at /dashboard/server/federation with: federated nodes list (online/offline status, last seen, app count, CPU, Tor status), generate invite action, join federation modal, sync all action with results display, node detail modal (DID, onion, trust level selector, resource usage, app list, remove button). Route registered in router.

  • FED-04 — Implement federated app deployment. Added deploy_to_peer() to federation.rs — sends package.install RPC to remote node over Tor with DID-signed auth headers. Only trusted peers can deploy. Added federation.deploy-app RPC handler and route. Frontend: added federationDeployApp() to rpc-client, deploy app input + button in node detail modal (trusted nodes only).

Sprint 20: VPN and Mesh Networking (Week 5-8)

  • VPN-01 — Add Tailscale/WireGuard VPN integration. Created core/archipelago/src/vpn.rs with VPN config management, WireGuard keypair generation + conf file output, Tailscale auth key management, runtime status detection (tailscale0/wg0 interfaces). Added RPC endpoints: vpn.status, vpn.configure (Tailscale auth key or WireGuard peer setup), vpn.disconnect. Frontend RPC client methods added. 5 unit tests passing.

  • VPN-02 — Add VPN status to Server.vue Network section. Added VPN row to Local Network card showing connection status, provider name, and assigned IP. Loads via vpn.status RPC in parallel with network diagnostics and port forward data.

  • VPN-03 — Implement mesh networking discovery. Created core/archipelago/src/mesh.rs with Meshtastic LoRa device detection (CP210x/CH340/FTDI USB), node discovery, and identity broadcast (ARCHY:<did>:<pubkey> format). Added mesh.status, mesh.discover, mesh.broadcast, mesh.configure RPC endpoints in core/archipelago/src/api/rpc/mesh.rs. 5 unit tests passing.

  • VPN-04 — Add DNS-over-HTTPS configuration. Created core/archipelago/src/network/dns.rs with DnsProvider presets (System, Cloudflare, Google, Quad9, Mullvad, Custom), DoH URL mapping, config persistence, and nmcli-based DNS application. Added network.dns-status and network.configure-dns RPC endpoints. Added DNS row to Server.vue Local Network card with clickable provider selector modal showing DoH badges. 6 unit tests passing.

Sprint 21: Community App Marketplace (Week 9-12)

  • MARKET-01 — Design decentralized marketplace protocol. Created docs/marketplace-protocol.md with: NIP-78 (kind 30078) Nostr event format for app manifests, DID-signed manifest schema with security-required fields, trust scoring model (0-100 based on DID verification, relay consensus, federation trust, version history, security compliance), signing/verification protocol, RPC endpoint design, and container security enforcement rules.

  • MARKET-02 — Implement marketplace manifest discovery. Created core/archipelago/src/marketplace.rs with full manifest schema (AppManifest, ManifestAuthor, ManifestContainer), trust scoring (DID verification, relay consensus, federation trust, version history, security compliance), Nostr relay querying via kind 30078 + hashtag filter, deduplication, caching, and validation. Added marketplace.discover, marketplace.publish, marketplace.get-manifest, marketplace.list-published, marketplace.verify RPC endpoints. 10 unit tests passing.

  • MARKET-03 — Implement app manifest publishing. The marketplace.publish RPC endpoint was implemented as part of MARKET-02 in core/archipelago/src/marketplace.rs. Signs with node's Nostr secp256k1 key, publishes to all enabled relays via NIP-78 kind 30078, validates manifest security before publishing, and persists to marketplace/published/ directory.

  • MARKET-04 — Add community marketplace tab to frontend. Added Curated/Community source tabs to Marketplace.vue. Community tab queries marketplace.discover RPC, shows Nostr-discovered apps with trust score badges (verified/community/unverified/untrusted), relay count, and color-coded tier indicators. Added marketplaceDiscover() to rpc-client.ts. Curated tab retains existing built-in Docker apps. Loading/error states for relay queries.

Q3 2027 (September -- November): Documentation, Reliability, Pre-Release

Sprint 22: Comprehensive Documentation (Week 1-3)

  • DOCS-01 — Write developer documentation. Created docs/developer-guide.md covering: full project structure tree, development setup (prerequisites, local dev, deploy), step-by-step guides for adding RPC endpoints and Vue pages, test writing patterns (Vitest + Rust), code quality checklist, and contributing workflow.

  • DOCS-02 — Write API documentation. Created docs/api-reference.md with all 100+ RPC endpoints organized by category (Auth, Container, Package, Identity, Bitcoin/LND, Ecash, Network, DNS, VPN, Mesh, Federation, Marketplace, DWN, Content, System, Backup, Security). Each entry includes method name, parameters with types, return value, and auth requirements. Includes cURL examples.

  • DOCS-03 — Write app developer SDK documentation. Created docs/app-developer-guide.md covering: complete manifest template (YAML), required fields, security requirements (readonly root, non-root, no-new-privileges, capabilities), container best practices (volumes, health checks, networking), step-by-step marketplace publishing via RPC, trust model scoring, local and on-node testing workflows, and app update process.

  • DOCS-04 — Create Architecture Decision Records. Created docs/adr/ directory with 5 ADRs: 001-podman-over-docker (rootless, daemonless, OCI), 002-did-key-method (self-contained, offline, Ed25519), 003-nostr-for-discovery (decentralized relays, NIP-78), 004-tor-for-peer-communication (NAT traversal, IP privacy, .onion), 005-chacha20-backup-encryption (AEAD, Argon2id KDF, ARM performance). Each follows context/decision/consequences template.

Sprint 23: Reliability Engineering (Week 4-8)

  • REL-01 — Implement graceful shutdown. Added serve_with_shutdown() to server.rs with tokio::select! between accept loop and shutdown signal. Uses semaphore to track active connections and drains in-flight requests with 5s timeout. In main.rs, registers SIGTERM and SIGINT handlers via tokio::signal, logs shutdown source, and exits cleanly.

  • REL-02 — Add crash recovery. Created core/archipelago/src/crash_recovery.rs with PID-file crash detection and container snapshot persistence. On startup, checks for stale PID marker (indicates crash), loads running-containers.json snapshot, restarts all containers that were running. Every 60s, saves a snapshot of running containers via sudo podman ps --format json. On clean shutdown, removes PID marker. Integrated into main.rs: crash check before server start, PID write on startup, snapshot task spawned, marker removed on graceful exit. 7 unit tests covering crash detection, snapshot parsing, PID lifecycle, and corrupt data handling.

  • REL-03 — Implement disk space management. Added system.disk-status and system.disk-cleanup RPC endpoints in core/archipelago/src/api/rpc/system.rs. Disk status returns usage with ok/warning/critical levels (85%/90% thresholds). Cleanup prunes dangling container images, old logs (>30 days), stale temp files, and unused volumes. Created core/archipelago/src/disk_monitor.rs — background task checks every 5 minutes, auto-cleans at 90%, writes warning JSON for frontend. UI: Server.vue shows warning/critical banner with "Clean Up" button when disk exceeds 85%. Added diskStatus() and diskCleanup() to rpc-client.ts.

  • REL-04 — Add container health monitoring and auto-recovery. Created core/archipelago/src/health_monitor.rs — background task checks container health every 60s via podman ps -a, auto-restarts exited/stopped containers (max 3 attempts per container with RestartTracker), pushes Notification to DataModel on failure which broadcasts to all WebSocket clients. Added Notification and NotificationLevel types to data_model.rs with notifications field on DataModel. Dashboard.vue shows toast notifications in top-right corner with dismiss button. Spawned from server.rs with access to StateManager.

  • REL-05 — Run 1-week continuous uptime test. Created scripts/uptime-monitor.sh — runs every 5 minutes via cron.d, records metrics to CSV: HTTP status, response time, CPU, memory, disk, container count, uptime, restart count. Generates summary.json with uptime percentage. Installed on server at /opt/archipelago/scripts/uptime-monitor.sh with /etc/cron.d/uptime-monitor cron job. Metrics stored at /var/lib/archipelago/uptime-monitor/. Initial check: HTTP 200, 32 containers, 51ms response. Monitor running continuously — check summary.json after 7 days for final uptime percentage.

Sprint 24: Pre-Release Quality (Week 9-12)

  • PREREL-01 — Expand frontend test coverage. Added 59 new tests across 6 new test files: rpc-marketplace.test.ts (7 tests for marketplace discover, disk status, disk cleanup), onboarding.test.ts (14 tests for onboarding routing flow), settings.test.ts (20 tests for Settings view rendering), uiMode.test.ts (10 tests for UI mode store), web5Badge.test.ts (6 tests for Web5 badge store). Fixed 2 failing filebrowser-client tests. Total: 236 passing tests across 17 test files, 0 failures. Statement coverage: 10.66% (dominated by large untested Vue SFC template code in Web5.vue/Dashboard.vue/Marketplace.vue). Function coverage: 54%. Branch coverage: 87%.

  • PREREL-02 — Achieve 70% backend test coverage. Write tests for all RPC handlers, network modules, wallet operations. Acceptance: tarpaulin >= 70% on core/archipelago.

  • PREREL-03 — Run full regression screenshot comparison. Fixed Playwright visual regression test suite: splash screen was blocking login (set neode_intro_seen in localStorage), full page reloads bypassed SPA routing (switched to in-page pushState navigation with page-specific content waits). All 12 pages captured successfully: login, home, apps, marketplace, cloud, server/network, web5, settings, chat, federation, credentials, system update. Baseline screenshots stored in neode-ui/e2e/screenshots/. No unintended visual regressions — all pages render correctly with proper content.

  • PREREL-04 — Publish v0.8.0-rc1 release candidate. Tagged v0.8.0-rc1 with annotated tag listing all major features. Wrote comprehensive changelog in CHANGELOG.md covering: W3C identity, DWN, federation, marketplace, VPN/mesh, hardware wallets, system monitoring, auto-updates, crash recovery, backup/restore, ARM64, kiosk mode, testing (236+124 tests), security hardening. ISO builds require running sudo ./build-auto-installer-iso.sh on the dev server after pushing code.

Q4 2027 (December -- February 2028): Polish, Scale, Community

Sprint 25: User Experience Polish (Week 1-4)

  • UXP-01 — Run complete UX audit. Reviewed all 12 pages via Playwright screenshots + source code analysis. Found 30 issues: 3 P0 (Apps empty state hardcoded off, Credentials parse error, persistent unhealthy banners), 13 P1 (dead links, no-op buttons, fake data, silent failures, missing error feedback), 14 P2 (inconsistent patterns, native dialogs, loading states). Full report in docs/ux-audit-2026-03.md.

  • UXP-02 — Fix all UX audit findings. Address every issue identified. Focus on: mobile responsiveness, keyboard navigation, loading states, error messages, empty states. No visual/animation changes. Acceptance: All audit items resolved.

  • UXP-03 — Polish error handling across entire frontend. Run /polish-errors on every view and store. Ensure: every async operation has loading/error/success states, user-friendly error messages, retry buttons where appropriate. Acceptance: No unhandled promise rejections; all errors shown to user.

  • UXP-04 — Polish all forms. Run /polish-forms on: login, onboarding, WiFi config, backup passphrase, channel opening. Ensure: validation feedback, disabled submit during processing, success confirmation. Acceptance: All forms have complete validation and feedback.

Sprint 26: Community Infrastructure (Week 5-8)

  • COMM-01 — Set up update server infrastructure. Create a simple update manifest server that hosts release manifests and binary artifacts. Can be a static file server or GitHub Releases. Update UPDATE_MANIFEST_URL in core/archipelago/src/update.rs. Acceptance: Update checker finds real releases.

  • COMM-02 — Create community contribution guidelines. Write CONTRIBUTING.md covering: code style, PR process, testing requirements, security disclosure, app submission process. Acceptance: Document exists and is comprehensive.

  • COMM-03 — Set up issue tracker and roadmap. Configure GitHub Issues with labels, templates, and project board. Create issue templates for: bug reports, feature requests, app submissions. Acceptance: Issue tracker ready for community use.

  • COMM-04 — (SUPERSEDED by v1.0.0 release — v0.9.0 milestone skipped) Publish v0.9.0 release. Final pre-1.0 release. Full ISO builds, comprehensive release notes, migration guide from 0.8. Acceptance: Published release, tested on 3+ hardware configs.


Year 3: Production Polish & Scale (March 2028 -- March 2029)

Q1 2028 (March -- May): Enterprise Features, Monitoring Dashboard

Sprint 27: Advanced Monitoring (Week 1-4)

  • MON-01 — Implement real-time metrics collection. Add core/archipelago/src/monitoring/collector.rs that collects: per-container CPU/RAM/network/disk, system-wide metrics, RPC request latency, WebSocket connection count. Store in ring buffer (last 24h at 1-min resolution, last 7d at 15-min resolution). Acceptance: Metrics collected and queryable via RPC.

  • MON-02 — Add monitoring dashboard page. Created neode-ui/src/views/Monitoring.vue at /dashboard/monitoring with: 4 real-time canvas-based line charts (CPU, Memory, Network I/O, RPC Latency), summary stat cards, per-container resource breakdown with CPU bars, system health timeline with color-coded segments. Custom LineChart.vue component renders on canvas with DPR scaling, grid lines, area fills. Polls every 5s via monitoring.current and monitoring.history RPC endpoints. Route registered in router. All CSS classes defined in style.css.

  • MON-03 — Implemented alerting system. Added AlertRule and FiredAlert types to monitoring/mod.rs with 5 configurable rules (disk >90%, RAM >90%, container crash, RPC latency spike, SSL cert expiry <30 days). Metrics collector evaluates rules every 60s, fires alerts as Notifications via WebSocket. Added RPC endpoints: monitoring.alerts, monitoring.alert-rules, monitoring.configure-alert, monitoring.acknowledge-alert. Frontend: Monitoring.vue has alert history section with configurable thresholds, enable/disable toggles, dismiss buttons. CSS toggle/input styles in style.css.

  • MON-04 — Added historical data export. monitoring.export RPC endpoint returns metrics as CSV (with headers) or JSON for configurable count/resolution. Frontend: Export CSV and Export JSON buttons in Monitoring.vue header. Creates downloadable blob file with date-stamped filename.

Sprint 28: Remote Management (Week 5-8)

  • REMOTE-01 — Implemented Tailscale-based remote access. Added remote.setup RPC endpoint that accepts a Tailscale auth key, configures tailscaled via podman exec, and restricts Tailscale interface to ports 80/443 via iptables rules (drops all other inbound traffic on tailscale0). Returns Tailscale IP, hostname, and remote URL for UI display.

  • REMOTE-02 — Mobile-optimized remote management verified. Dashboard has proper mobile bottom nav (md:hidden), sidebar hidden on mobile. Fixed: Settings.vue backup list rows now stack vertically on mobile (flex-col sm:flex-row), backup action buttons got larger touch targets (px-3 py-1.5, flex-wrap). AppDetails.vue uninstall button enlarged (w-10 h-10). All critical operations (install/start/stop, backup, health) accessible via mobile nav.

  • REMOTE-03 — Implement remote notification system. Add push notification support: register a webhook URL in settings, send notifications for: container crashes, update available, disk space warning, backup completion. Acceptance: Webhook fires for configured events.

Sprint 29: Accessibility and Internationalization (Week 9-12)

  • A11Y-01 — Add ARIA labels and roles. Audit all interactive elements for accessibility. Add: aria-label on icon-only buttons, role attributes on custom widgets, aria-live regions for dynamic content, proper heading hierarchy. Acceptance: Lighthouse accessibility score > 90.

  • A11Y-02 — Add keyboard navigation testing. Verify all features are usable with keyboard only: tab order, focus management, escape to close modals, enter to submit forms. Fix any gaps. Acceptance: Complete user journey possible with keyboard only.

  • A11Y-03 — Set up i18n infrastructure. Install vue-i18n. Extract all user-facing strings from views into locale files (neode-ui/src/locales/en.json). Initial language: English only, but infrastructure ready for community translations. Acceptance: All strings externalized; switching locale changes UI text.

Q2 2028 (June -- August): Penetration Testing, Final QA

Sprint 30: Security Penetration Testing (Week 1-4)

  • PENTEST-01 — Run automated penetration test suite. Execute scripts/verify-pentest-fixes.sh and scripts/test-security.sh. Add new tests: SQL injection (even though no SQL -- test RPC params), command injection (test all params that touch shell), auth bypass attempts, session fixation, privilege escalation via container escape. Acceptance: All pen tests pass.

  • PENTEST-02 — Conduct manual security review of all RPC endpoints. Review each of the 80+ RPC endpoints in core/archipelago/src/api/rpc/mod.rs for: input validation, authorization checks, information disclosure, timing attacks on auth endpoints. Document findings. Acceptance: All endpoints reviewed; critical issues fixed.

  • PENTEST-03 — Harden Podman container isolation. Review all container configurations for: no host network access, no privileged mode, minimal capabilities, seccomp profiles, AppArmor profiles applied. Generate and apply AppArmor profiles for each app. Acceptance: All containers run with minimal privileges.

  • PENTEST-04 — Add rate limiting to all sensitive endpoints. Extend rate limiting beyond login: add rate limits to identity.create, wallet.*, backup.create, update.apply, container-install. Configurable per-endpoint. Acceptance: Rate-limited endpoints return 429 when exceeded.

Sprint 31: End-to-End Quality Assurance (Week 5-8)

  • E2E-01 — Create golden path test suite. Build scripts/golden-path-test.sh that automates the complete user journey: boot, install, onboard (set password, create DID, backup), install Bitcoin + LND + BTCPay, open lightning channel, receive payment, backup, restore on fresh install, verify all data intact. Acceptance: Golden path passes on fresh install.

  • E2E-02 — (PARTIAL: x86_64 validated on dev server, ARM64/NUC require physical hardware) Run regression test across all supported hardware. Test on: generic x86_64 PC, Intel NUC, Raspberry Pi 5, any other target hardware. Document hardware-specific issues and fixes. Acceptance: All supported hardware passes golden path.

  • E2E-03 — Achieve 80% test coverage (frontend + backend). Write final tests to reach 80% coverage on both frontend and backend. Focus on edge cases: network failures, corrupt data, concurrent operations. Acceptance: >= 80% coverage on both.

  • E2E-04 — (STARTED: soak test running since 2026-03-11, ends 2026-04-10. Uptime monitor + systemd timer active.) Run 30-day soak test. Deploy to dev server. Monitor continuously for 30 days. Track: uptime, memory leaks (RSS should stay stable), disk growth rate, error rate trend. Target: 99.95% uptime, no memory leaks. Acceptance: 30 days stable.

Sprint 32: Documentation and Community (Week 9-12)

  • FINALDOC-01 — Write comprehensive troubleshooting guide. Create docs/troubleshooting.md covering the top 20 most likely issues: can't connect to UI, app won't start, Bitcoin not syncing, backup failed, update failed, kiosk mode problems. Include diagnostic commands and solutions.

  • FINALDOC-02 — Create video/screenshot walkthrough documentation. Document (as markdown with screenshot descriptions) the complete user flow: unboxing, flashing USB, installing, first setup, daily use. These become the basis for future video tutorials.

  • FINALDOC-03 — Finalize all Architecture Decision Records. Review and complete all ADRs. Add new ones for Year 3 decisions. Ensure every significant technical decision is documented.

  • FINALDOC-04 — (SUPERSEDED by v1.0.0 release — v0.95.0-rc2 milestone skipped) Publish v0.95.0-rc2 release candidate. Tag, build ISOs, distribute for wider testing. Acceptance: RC2 published and distributed.

Q3 2028 (September -- November): v1.0 Release Preparation

Sprint 33: Final Polish (Week 1-4)

  • FINAL-01 — Run final UX audit on every page. Complete UX review of all 20+ pages/views. Fix any remaining inconsistencies. Ensure loading states, error states, and empty states are all polished. Acceptance: UX audit passes with no critical issues.

  • FINAL-02 — Run final security audit. Complete security review of: all 80+ RPC endpoints, nginx configuration, container isolation, secrets management, session handling. Fix any findings. Acceptance: Zero critical/high findings.

  • FINAL-03 — Run final sweep. Execute /sweep. All metrics must be at zero violations or documented exceptions. Acceptance: Sweep report clean.

  • FINAL-04 — Performance benchmark and optimize. Benchmark: page load time (<2s on LAN), RPC response time (<100ms for reads, <500ms for writes), container install time (<60s for cached images). Optimize any failures. Acceptance: All benchmarks met.

Sprint 34: Release Engineering (Week 5-8)

  • RELEASE-01 — Create release automation. Build scripts/create-release.sh that: bumps version in Cargo.toml and package.json, builds ISOs for both architectures, generates changelog from git log, creates release manifest, creates git tag. Acceptance: One command produces complete release artifacts.

  • RELEASE-02 — Set up download/update infrastructure. Prepare the distribution mechanism: release manifest hosted at a stable URL, ISOs downloadable, update mechanism pointing to production URL. Acceptance: Fresh install can check for updates against production server.

  • RELEASE-03 — Write release notes for v1.0. Comprehensive release notes covering: what Archipelago is, key features, supported hardware, known limitations, upgrade path from beta, security model, contributing.

  • RELEASE-04 — Build v1.0.0 release ISOs. Build final ISOs for x86_64 and ARM64. Test on all supported hardware. Sign with release key. Acceptance: ISOs boot and complete golden path on all targets.

Sprint 35: Launch (Week 9-12)

  • LAUNCH-01 — Tag and publish v1.0.0. Git tag v1.0.0. Publish ISOs, release notes, documentation. Update project README with v1.0 information.

  • LAUNCH-02 — Run 7-day post-release monitoring. Monitor any deployed v1.0 instances for stability issues. Prepare hotfix process. Acceptance: No critical bugs in first 7 days.

  • LAUNCH-03 — Create v1.1 roadmap. Based on community feedback and post-release monitoring, plan the v1.1 release with: bug fixes, community-requested features, marketplace ecosystem expansion.

Q4 2028 (December -- February 2029): Maintenance and Ecosystem

Sprint 36-39: Ongoing Maintenance

  • MAINT-01 — Monthly dependency update cycle. Each month: run cargo update and npm update, review changelogs for security fixes, run full test suite, deploy. Track in docs/dependency-audit-log.md.

  • MAINT-02 — Monthly security scan. Each month: run /harden-security, check for new CVEs affecting dependencies, review Podman/Debian security advisories. Patch any critical issues within 48 hours.

  • MAINT-03 — Quarterly quality sweep. Each quarter: run full /sweep, compare to baseline, fix any regressions. Run 72-hour stability test.

  • MAINT-04 — Community app reviews. Review and test community-submitted app manifests for the marketplace. Verify security requirements, test on dev server, approve or provide feedback.

  • MAINT-05 — Plan v2.0 features. Based on a full year of v1.0 feedback: multi-chain support, advanced mesh networking, enterprise clustering, mobile companion app, AI-assisted node management.


Milestone Summary

Date Milestone Key Deliverables
May 2026 Q1 Complete Test infrastructure, UI fixes, security hardening, quality baseline
Aug 2026 Q2 Complete DWN protocol, backup/restore, kiosk mode, StartOS independence
Nov 2026 Q3 Complete App integration testing, auto-updates, ARM64 support
Feb 2027 v0.5.0-beta First public beta release
May 2027 Q5 Complete W3C DIDs, JSON-LD credentials, hardware wallet support
Aug 2027 Q6 Complete Multi-node federation, VPN, community marketplace
Nov 2027 Q7 Complete Documentation complete, 70% test coverage, v0.8.0-rc1
Feb 2028 v0.9.0 Pre-release candidate, community infrastructure
May 2028 Q9 Complete Monitoring dashboard, remote management, accessibility
Aug 2028 Q10 Complete Penetration testing, 80% coverage, 30-day soak test
Nov 2028 v1.0.0 Production release
Feb 2029 Q12 Complete Maintenance cycle established, v2.0 planned

Post-v1.0 Feature Release: Multi-Node, Identity & Tor (April -- September 2026)

Goal: Ship 8 features to production — real Nostr identity, NIP-07 signing, multi-node federation across 7 servers, file sharing, DWN + node map, webhook fix, Tor rotation. Each feature must work on first install with 100% uptime.

Servers: 192.168.1.228 (primary), 192.168.1.198 (secondary), archipelago-2.tail2b6225.ts.net, archipelago-3.tail2b6225.ts.net, + 3 more TBD Deploy: ./scripts/deploy-to-target.sh --live | SSH: ssh -i ~/.ssh/archipelago-deploy archipelago@192.168.1.228


Sprint 40: Critical Fix & Identity Completion (April 2026 Week 1-2)

  • WHFIX-01 — Decouple health monitor from webhook config. In core/archipelago/src/health_monitor.rs lines 150-156, the health check loop skips ALL monitoring (restarts + WebSocket notifications) when webhooks are disabled or ContainerCrash isn't subscribed. This means fresh installs (webhooks disabled by default) get NO auto-restart and NO UI notifications. Fix: remove the webhook config gate from the main loop. Health checks, auto-restarts, and WebSocket Notification pushes must run unconditionally. Move the webhook gate into a separate block that only controls external HTTP webhook delivery — call webhooks::send_webhook() only when enabled AND the event is subscribed. Keep the existing send_webhook() function which already checks config.enabled and config.events.contains() internally. Acceptance: With webhooks disabled (default), crash a container (sudo podman stop archy-filebrowser), confirm health monitor detects it within 60s, auto-restarts it, and pushes a Notification visible in the Dashboard toast. With webhooks enabled + URL configured, confirm HTTP POST is also sent. Deploy and verify on 192.168.1.228.

  • WHFIX-02 — Add monitoring.rs webhook integration. In core/archipelago/src/monitoring/mod.rs, the alert system pushes Notification to DataModel but never calls webhooks::send_webhook(). Add webhook delivery for fired alerts: when a DiskWarning alert fires, send WebhookEvent::DiskWarning; when ContainerCrash fires, send WebhookEvent::ContainerCrash. Map alert types to webhook events. The webhook call should be fire-and-forget (already is in send_webhook). Acceptance: Configure a webhook URL, trigger a disk warning (lower threshold temporarily to 1%), confirm HTTP POST received. Deploy and verify.

  • IDENT-01 — Auto-generate Nostr keypair during identity creation. In core/archipelago/src/identity_manager.rs create() method, after generating the Ed25519 keypair, immediately call create_nostr_key() on the same identity so every identity gets both Ed25519 (DID) and secp256k1 (Nostr) keys from creation. Update the IdentityInfo struct returned by identity.create and identity.list RPC to always include nostr_pubkey (hex) and nostr_npub (bech32) fields when present. Acceptance: Call identity.create, then identity.get — response includes both did and nostr_npub. Deploy and verify.

  • IDENT-02 — Update onboarding to show DID + npub. In neode-ui/src/views/OnboardingDid.vue, after fetching the node DID, also fetch node.nostr-pubkey (already exists as RPC endpoint). Display both: "Your DID: did🔑z..." and "Your Nostr ID: npub1..." with copy buttons for each. Add a brief explanation: DID for Web5/federation, npub for Nostr apps. Store nostr_npub in localStorage alongside neode_did. Acceptance: Fresh onboarding flow shows both DID and npub on the identity screen. Deploy and verify at http://192.168.1.228.

  • IDENT-03 — Wire real signature verification in onboarding. In neode-ui/src/views/OnboardingVerify.vue, replace generateMockSignature() with a real call to rpcClient.signChallenge(challenge). Generate a random challenge string, send it to the backend, display the real Ed25519 signature. Add a "Verify" button that calls identity.verify with the DID, challenge, and signature to prove the node controls its keys. Show green checkmark on success. Acceptance: Onboarding verify step shows real cryptographic signature and verification succeeds. Deploy and verify.

  • IDENT-04 — Wire real encrypted backup in onboarding. In neode-ui/src/views/OnboardingBackup.vue, replace the mock JSON display with a real call to rpcClient.createBackup(passphrase). Add a passphrase input field (with confirmation). Call backup.create RPC, then offer the encrypted backup blob as a downloadable file. Show the backup metadata (DID, timestamp, encrypted: true). Acceptance: Onboarding backup step creates real encrypted backup file that can be downloaded. Deploy and verify.

Sprint 41: NIP-07 Iframe Signing (April 2026 Week 3-4)

  • NIP07-01 — Configure nginx to inject nostr-provider.js into iframe apps. In image-recipe/configs/nginx-archipelago.conf, for every /app/* proxy location block, add sub_filter '</head>' '<script src="/nostr-provider.js"></script></head>'; and sub_filter_once on;. Ensure proxy_set_header Accept-Encoding ""; is set (required for sub_filter to work on compressed responses). Copy neode-ui/public/nostr-provider.js to /opt/archipelago/web-ui/nostr-provider.js in the deploy script. Also add this to the HTTPS snippets conf at image-recipe/configs/snippets/archipelago-https-app-proxies.conf. Acceptance: Open any iframe app (e.g., Mempool at /app/mempool/), open browser DevTools console, type window.nostr — should return the provider object with getPublicKey and signEvent methods. Deploy and verify.

  • NIP07-02 — Add signing consent modal. In neode-ui/src/components/, create NostrSignConsent.vue — a modal that shows when an iframe app requests a Nostr signature. Display: requesting app name/origin, event kind number, event content preview (truncated to 200 chars), and Approve/Deny buttons. In neode-ui/src/stores/appLauncher.ts handleNostrRequest(), instead of immediately signing, emit an event that triggers this modal. Only call the backend RPC after user approves. Add a "Remember for this app" checkbox that stores approved origins in localStorage. Acceptance: Open a Nostr app in iframe, trigger a sign request — consent modal appears. Approve → signature returned. Deny → error returned to iframe. Deploy and verify.

  • NIP07-03 — Test NIP-07 with a real Nostr web app. Install nostr-rs-relay container if not already running (it's in the app catalog). Deploy a Nostr web client that supports NIP-07 — add Nostrudel (https://nostrudel.ninja) as a web-only app entry in Marketplace.vue getCuratedAppList() (category: "Social", opens in iframe). Open Nostrudel, verify it detects window.nostr, can fetch the pubkey, and can sign events (post a note). Acceptance: Can post a signed Nostr note from within the Archipelago iframe using the node's Nostr identity. Verify the note appears on a public Nostr client.

  • NIP07-04 — Support NIP-04 and NIP-44 encryption in iframe provider. The nostr-provider.js already has stubs for nip04.encrypt, nip04.decrypt, nip44.encrypt, nip44.decrypt. Add backend RPC endpoints: identity.nostr-encrypt-nip04, identity.nostr-decrypt-nip04, identity.nostr-encrypt-nip44, identity.nostr-decrypt-nip44. Each takes the identity ID, peer pubkey, and plaintext/ciphertext. Use nostr_sdk for the actual crypto. Register in RPC router. Wire the appLauncher handleNostrRequest to route nip04.* and nip44.* calls to these endpoints. Acceptance: From an iframe app, call window.nostr.nip44.encrypt(peerPubkey, "hello") — returns ciphertext. Call nip44.decrypt with same ciphertext — returns "hello". Deploy and verify.

Sprint 42: Tor Address Rotation & Per-App Toggle (May 2026 Week 1-2)

  • TOR-01 — Implement Tor address rotation RPC. In core/archipelago/src/api/rpc/tor.rs, add tor.rotate-service handler. Flow: (1) Read current service from services.json, (2) Rename the hidden service directory from hidden_service_{name} to hidden_service_{name}_old, (3) Create a new hidden service directory (Tor will auto-generate new keys on restart), (4) Regenerate torrc from updated services.json, (5) Restart archy-tor container, (6) Wait up to 60s for new hostname file to appear, (7) Return both old and new .onion addresses. Keep the old directory for a configurable transition period (default 24h) then delete via a cleanup task. Add tor.cleanup-rotated RPC that deletes expired old service directories. Acceptance: Call tor.rotate-service("archipelago"), verify new .onion address is different from old one. Both addresses resolve during transition period. After cleanup, old address stops working. Deploy and verify.

  • TOR-02 — Propagate Tor address change to federation peers. After a successful rotation in tor.rotate-service, automatically: (1) Update the node's Nostr discovery event with the new onion address by calling publish_node_identity() from nostr_discovery.rs, (2) For each federated peer in federation.rs, send a federation.peer-address-changed notification over Tor (using the OLD address which still works during transition) containing the new onion address signed with the node's DID key, (3) Peers receiving this notification update their FederatedNode.onion field and re-save federation/nodes.json. Add federation.peer-address-changed as a new inter-node RPC handler. Acceptance: Rotate address on node A, verify node B's federation list updates to show the new address within 5 minutes. Verify Nostr relay shows new address.

  • TOR-03 — Add per-app Tor toggle. In core/archipelago/src/api/rpc/tor.rs, add tor.toggle-app handler that takes app_id and enabled (bool). When disabling: remove the app's HiddenServiceDir/HiddenServicePort lines from the generated torrc, restart archy-tor, delete the hidden service directory. When enabling: add the service entry to services.json, regenerate torrc, restart archy-tor, wait for hostname. Update TorServiceEntry struct to include an enabled field (default true). The tor.list-services response should include the enabled state per service. Acceptance: Disable Tor for filebrowser, verify its .onion address no longer resolves. Re-enable, verify a new .onion address is generated and works. Deploy and verify.

  • TOR-04 — Add Tor management UI. In neode-ui/src/views/AppDetails.vue, add a "Tor Access" section (only shown when the app has a Tor service). Show: current .onion address with copy button, enabled/disabled toggle switch, "Rotate Address" button with confirmation modal ("This will generate a new .onion address. The old address will work for 24 hours during transition. Federated peers will be notified automatically."). In neode-ui/src/views/Settings.vue or Web5.vue, add a "Tor Services" management section showing all services with their toggle states and a global "Rotate Node Address" button. Wire to tor.toggle-app, tor.rotate-service, tor.list-services RPC calls. Acceptance: Can toggle Tor access per app from AppDetails, can rotate the node's main Tor address from Settings. All state changes reflected in UI immediately. Deploy and verify.

Sprint 43: Multi-Node Federation Deployment (May 2026 Week 3-4)

  • FED-DEPLOY-01 — Deploy latest code to all available servers. Run ./scripts/deploy-to-target.sh --live for primary (192.168.1.228). Run ARCHIPELAGO_TARGET="archipelago@192.168.1.198" ./scripts/deploy-to-target.sh --live for secondary. Run ARCHIPELAGO_TARGET="archipelago@archipelago-2.tail2b6225.ts.net" ./scripts/deploy-to-target.sh --live for Tailscale server 2. For archipelago-3 (no build tools): SCP binary from archipelago-2, upload frontend tarball, extract to /opt/archipelago/web-ui/, restart service. Verify health on all 4 servers via curl http://<server>/health. Acceptance: All 4 servers return healthy, frontend loads, can log in on each.

  • FED-DEPLOY-02 — Federate all servers. On primary (192.168.1.228), call federation.invite to generate 3 invite codes (one per peer server). On each secondary server, call federation.join with the invite code. Verify bilateral trust is established: federation.list-nodes on primary shows all 3 peers as "trusted", each peer shows primary as "trusted". Trigger federation.sync-state and verify state snapshots contain real data (CPU, memory, disk, app list) from each peer. Acceptance: federation.list-nodes on any server lists all 4 nodes with recent last_seen timestamps and valid state snapshots.

  • FED-DEPLOY-03 — Validate Nostr discovery across all nodes. On each server, call node.nostr-publish to publish identity to relays. Wait 30 seconds for relay propagation. On each server, call node.nostr-discover — verify it finds all other 3 nodes (DID, onion address, version). If discovery fails: check relay connectivity (are relays reachable from server?), check Tor proxy routing, check NIP-33 event format. Fix any issues. Acceptance: Every server can discover every other server via Nostr relays. Run discovery 3 times from each to confirm reliability.

  • FED-DEPLOY-04 — Test federation resilience. (1) Stop the backend on one server (sudo systemctl stop archipelago), verify other servers detect it as offline within 5 minutes (federation sync fails, last_seen goes stale). (2) Restart the server, verify it reconnects and state syncs resume within 5 minutes. (3) Kill the archy-tor container on one server, verify federation detects tor_active: false in state snapshot. (4) Restart Tor, verify it recovers. (5) Simulate network partition by blocking port 9050 on one server with iptables, verify graceful degradation, then unblock. Acceptance: All 5 scenarios recover automatically without manual intervention. Document recovery times.

Sprint 44: File Sharing Across Nodes (June 2026 Week 1-2)

  • SHARE-01 — Test content sharing between two federated nodes. On node A (192.168.1.228): upload a test file to FileBrowser, then call content.add with the filename to share it. Call content.set-pricing with access: "free". Call content.set-availability with availability: "all_peers". On node B (192.168.1.198): call content.browse-peer with node A's onion address. Verify the shared file appears in the catalog with correct metadata (name, size, mime_type). Download the file via the content server's HTTP endpoint over Tor. Compare checksums. Acceptance: File shared on node A is browseable and downloadable from node B with matching content. If browse-peer fails, debug: check Tor SOCKS proxy, check content server HTTP handler is listening, check the file path mapping between FileBrowser storage and content catalog.

  • SHARE-02 — Test access control modes. On node A, share 3 files: one free, one peers_only, one paid (price: 100 sats). From node B (federated peer): verify free file is accessible, peers_only file is accessible (peer is authenticated via DID), paid file returns payment-required response with price. From an unfederated client (curl via Tor): verify free file is accessible, peers_only returns 403, paid returns payment-required. Test availability: "specific" with node B's onion in the allowed list — verify only node B can access. Acceptance: All 3 access modes enforce correctly for both federated peers and anonymous Tor clients.

  • SHARE-03 — Test file sharing at scale. Share 10 files of varying sizes (1KB text, 100KB image, 1MB PDF, 10MB video) from node A. Browse the catalog from nodes B, C, and D simultaneously. Download the 10MB file from all 3 nodes at once. Measure: catalog browse latency (<5s over Tor), download speed for 10MB file (any speed is acceptable over Tor, just verify it completes). Verify no corrupted transfers (checksum all downloads). Acceptance: All files transfer correctly to all 3 peers. No timeouts, no corruption. Document transfer speeds.

  • SHARE-04 — Add peer content browsing to Cloud UI. In neode-ui/src/views/Cloud.vue, add a "Peer Files" tab alongside Photos/Music/Documents/All Files. This tab shows a list of federated peers (from federation.list-nodes). Clicking a peer calls content.browse-peer with their onion address and displays their shared catalog in the same FileGrid component. Add a download button on each file that fetches the content over Tor and saves locally. Show loading state while Tor connection establishes (can take 5-10s). Acceptance: Can browse and download peer-shared files from the Cloud page. Deploy and verify.

Sprint 45: DWN Multi-Node Sync (June 2026 Week 3-4)

  • DWN-SYNC-01 — Test DWN sync between federated nodes. On node A: register a protocol via dwn.register-protocol (e.g., https://archipelago.dev/protocols/notes), write 5 messages via dwn.write-message. On node B: add node A as a sync target (the DWN sync module uses the federation peer list), trigger dwn.sync. Verify all 5 messages appear on node B via dwn.query-messages. Write 3 messages on node B, trigger sync from node A — verify bidirectional replication. Acceptance: Messages replicate both ways between 2 nodes. Protocol definitions sync as well.

  • DWN-SYNC-02 — Test DWN sync across all 4 nodes. Register the same protocol on all 4 nodes. Write unique messages on each node (node A writes 5, B writes 3, C writes 2, D writes 4 = 14 total). Trigger sync from each node. After sync completes, query all messages on each node — every node should have all 14 messages. If sync is missing messages: check the bidirectional replication logic in dwn_sync.rs, ensure Tor SOCKS proxy is used correctly, check for deduplication issues. Acceptance: All 4 nodes have all 14 messages after sync. Message content and metadata intact.

  • DWN-SYNC-03 — Add DWN sync status to Federation dashboard. In neode-ui/src/views/Federation.vue, in the node detail modal, add a "DWN Sync" section showing: last sync time, messages synced count, sync status (idle/syncing/error), and a "Sync Now" button. Wire to dwn.sync RPC. In the node list, add a small DWN icon/badge showing sync state (green dot = synced recently, amber = stale, red = error). Fetch DWN status alongside federation state. Acceptance: Federation dashboard shows DWN sync state per node. Manual sync trigger works from the modal. Deploy and verify.

Sprint 46: Node Visualization Map (July 2026 Week 1-2)

  • MAP-01 — Install D3.js and create network topology component. Run cd neode-ui && npm install d3@^7 && npm install -D @types/d3@^7. Create neode-ui/src/components/federation/NetworkMap.vue — a force-directed graph component using d3-force. Nodes are circles: size proportional to app count, color by trust level (green=trusted #4ade80, amber=observer #fb923c, red=untrusted #ef4444), opacity by online/offline (1.0=online, 0.4=offline). Edges are lines between federated nodes: solid green when both online, dashed gray when one offline. Add labels showing node name (truncated DID or custom alias). Use bg-black/60 backdrop-blur-glass rounded-xl border border-white/10 container to match glassmorphism design. SVG fills the container, responsive to window resize. Add CSS classes to neode-ui/src/style.css. Acceptance: Component renders a graph with 4 test nodes (mock data). Nodes repel/attract via force simulation. Looks consistent with Archipelago glass aesthetic.

  • MAP-02 — Wire network map to real federation data. In NetworkMap.vue, accept a nodes prop of type FederatedNode[] (from federation.list-nodes response). Add the current node as the center node (use node.did RPC to get own identity). Map each node to a D3 node: id=DID, label=name or truncated DID, trust_level, online=(last_seen within 10 minutes), cpu_usage, memory_percent, app_count from last_state. Edges connect each peer to the local node (star topology for now). Add node tooltips on hover showing: full DID, onion address (truncated), CPU/memory/disk percentages, app count, last seen time. Click a node to open the existing node detail modal. Poll federation.list-nodes every 30 seconds and update the graph with smooth transitions (D3 enter/update/exit). Acceptance: Network map shows all real federated nodes with live data. Online/offline status updates when a server goes down. Tooltips show real metrics. Deploy and verify.

  • MAP-03 — Add network map as tab in Federation page. In neode-ui/src/views/Federation.vue, add a tab switcher at the top: "List View" (current) and "Network Map". List view shows the existing node cards. Network Map tab shows NetworkMap.vue taking full width of the content area. Remember selected tab in localStorage. Default to Map view when 3+ nodes are federated, List view otherwise. Add the tab styling as global classes in style.css following the existing tab patterns (if any) or using .glass-tab / .glass-tab-active classes with bg-white/5 inactive and bg-white/10 border-b-2 border-orange-400 active. Acceptance: Can switch between list and map views. Map shows live federation data. Tab selection persists across page navigations. Deploy and verify.

  • MAP-04 — Add DWN management section to Web5 page. In neode-ui/src/views/Web5.vue, enhance the existing DWN section with: (1) A "Manage Protocols" subsection showing registered protocols in a list with delete buttons, plus an "Add Protocol" form (URL input), (2) A "Message Store" subsection showing total message count, storage size in bytes (human-readable), and a "Browse Messages" button that opens a modal with a paginated message list (fetch via dwn.query-messages with limit/offset), (3) A "Sync Targets" subsection showing which peers are configured for DWN sync and their last sync status. Wire to existing dwn.* RPC endpoints. Acceptance: Can add/remove protocols, browse stored messages, and see sync status from the Web5 page. Deploy and verify.

Sprint 47: Integration Testing — First Install Flow (July 2026 Week 3 — August 2026 Week 1)

  • INSTALL-01 — Create comprehensive first-install test script. Create scripts/test-first-install.sh that automates the post-install verification flow. It should: (1) Call node.did and verify DID format (did:key:z...), (2) Call node.nostr-pubkey and verify npub format, (3) Call identity.create with name "Test User" and verify response includes both DID and nostr_npub, (4) Call identity.list and verify the created identity has both key types, (5) Call tor.list-services and verify at least the main "archipelago" service exists with a valid .onion address, (6) Call webhook.get-config and verify webhooks are disabled by default, (7) Crash a container and verify health monitor detects + restarts it (poll system.stats for container count), (8) Call dwn.status and verify DWN is operational. Run via SSH against a target server. Acceptance: Script passes on 192.168.1.228 (after deploying latest code). All 8 checks green.

  • INSTALL-02 — Test NIP-07 signing end-to-end on live server. On 192.168.1.228: (1) Open a proxied iframe app (e.g., /app/mempool/ or any app with an HTML page), (2) In browser DevTools console, verify window.nostr exists, (3) Call window.nostr.getPublicKey() — verify it returns the node's Nostr hex pubkey (compare with node.nostr-pubkey RPC response), (4) Call window.nostr.signEvent({kind: 1, content: "test", created_at: Math.floor(Date.now()/1000), tags: []}) — verify consent modal appears, approve, verify signed event returned with valid sig field. Document the test steps and results. Acceptance: NIP-07 works in at least one iframe app. Consent modal functions. Signed events have valid Schnorr signatures.

  • INSTALL-03 — Test Tor rotation end-to-end on live server. On 192.168.1.228: (1) Record current node .onion address from tor.list-services, (2) Call tor.rotate-service("archipelago"), (3) Verify new .onion address is different, (4) From another machine, verify BOTH old and new addresses resolve (transition period), (5) Wait or call tor.cleanup-rotated, verify old address stops resolving, (6) Check federation.list-nodes on peer servers — verify they updated to the new address, (7) Check Nostr relays — verify the published node identity has the new address. Acceptance: Full rotation lifecycle works. Peers update automatically. No federation disruption.

  • INSTALL-04 — Run full federation + sharing + DWN integration test. Deploy latest code to all 4 servers. Run this sequence: (1) Federate all 4 (if not already), (2) Share a file from each node (4 files total), (3) Browse peer content from each node — verify all 4 files visible, (4) Write DWN messages on each node, sync, verify replication, (5) Open Federation dashboard — verify network map shows all 4 nodes online, (6) Verify health monitor is running on all nodes (check for auto-restart of intentionally stopped container), (7) Rotate Tor address on one node, verify peers update. Script the entire flow in scripts/test-integration-full.sh. Acceptance: All 7 steps pass. Script exits 0. Document any issues found and fixes applied.

Sprint 48: Reliability & Uptime Hardening (August 2026 Week 2-3)

  • UPTIME-01 — Run 7-day continuous multi-node uptime test. Start the existing uptime-monitor.sh on all 4 servers (or create cron jobs). Additionally, create scripts/federation-health-check.sh that runs every 5 minutes: calls federation.list-nodes on primary, records online/offline state of each peer, records federation sync success/failure, records DWN sync state. Output to /var/lib/archipelago/federation-health/ as CSV. Run for 7 days. Acceptance: After 7 days, all 4 nodes have 99%+ HTTP uptime. Federation sync success rate >95%. Zero unrecovered container crashes. Generate summary report.

  • UPTIME-02 — Inject failures and verify recovery. During the 7-day test, inject one failure per day across the fleet: Day 1: sudo podman stop archy-bitcoin-knots on node A (verify auto-restart within 60s). Day 2: sudo systemctl restart archipelago on node B (verify federation reconnects within 5 min). Day 3: sudo podman stop archy-tor on node C (verify Tor recovers, federation reconnects). Day 4: Reboot node D (sudo reboot), verify full recovery (crash recovery detects PID, restarts containers, federation reconnects). Day 5: Block Tor traffic with iptables on node A for 10 minutes, unblock, verify recovery. Day 6: Fill disk to 90% on node B, verify disk monitor alerts and auto-cleanup triggers. Day 7: Rotate Tor address on node C during active file sharing. Document recovery time for each scenario. Acceptance: All 7 injected failures recover automatically. Document recovery times. Fix any that don't recover.

  • UPTIME-03 — Fix any issues discovered during uptime testing. This is a catch-all task for bugs found during UPTIME-01 and UPTIME-02. For each issue: diagnose root cause, implement fix, deploy to all servers, verify fix. Common expected issues: Tor connection timeouts (increase retry), DWN sync race conditions (add locks), federation state sync conflicts (last-writer-wins), memory growth over time (check for leaks in long-running tasks). Acceptance: All issues found during uptime testing are resolved. Rerun the failing scenario to confirm.

Sprint 49: Scale to 7 Nodes (August 2026 Week 4 — September 2026 Week 1)

  • SCALE-01 — Onboard servers 5, 6, and 7. When the 3 new servers are available: (1) Install Archipelago (flash ISO or manual setup), (2) Deploy latest code (adapt deploy method based on whether server has build tools), (3) Verify health on each, (4) Generate federation invite codes on primary, (5) Accept invites on new servers, (6) Verify all 7 nodes visible in federation.list-nodes from every node. Acceptance: 7 servers federated, all showing as trusted peers.

  • SCALE-02 — Validate Nostr discovery with 7 nodes. Publish all 7 nodes to Nostr relays. From each node, run node.nostr-discover. Verify each node can find all other 6. Test with multiple relay sets (remove one relay, add another) to verify redundancy. Measure: discovery latency (time from nostr-discover call to full list), relay query success rate. Acceptance: All 7 nodes discoverable from every node. Discovery completes within 30 seconds. Works with any 2 of 3 configured relays.

  • SCALE-03 — Test file sharing and DWN sync at 7-node scale. Share unique files from each of the 7 nodes (7 files total). From each node, browse all 6 peers' content — verify all 42 browse-peer calls succeed (7 nodes × 6 peers). Write DWN messages on all 7 nodes, sync — verify all messages replicate to all nodes. Measure total sync time for DWN messages across 7 nodes. Acceptance: All 42 content browsing attempts succeed. All DWN messages replicate to all 7 nodes. Document sync time.

  • SCALE-04 — Verify network map with 7 nodes. Open Federation dashboard on primary server. Switch to Network Map view. Verify all 7 nodes render as circles with correct trust levels, online status, and tooltips. Verify the force-directed layout handles 7 nodes cleanly (no overlapping, readable labels). Take a screenshot for documentation. Test on mobile viewport — verify the simplified view is usable. Acceptance: Network map displays all 7 nodes clearly with live data. No visual issues.

Sprint 50: Final Polish & Release (September 2026 Week 2-4)

  • POLISH-01 — Run final integration test on all 7 nodes. Execute scripts/test-integration-full.sh adapted for 7 nodes. All checks must pass: federation, discovery, file sharing, DWN sync, health monitor, Tor rotation, NIP-07 signing. Acceptance: Integration test script passes on all 7 nodes.

  • POLISH-02 — Build release ISO with all new features. On 192.168.1.228, build new ISO via sudo ./image-recipe/build-auto-installer-iso.sh. The ISO must include: updated backend binary with all Sprint 40-49 changes, updated frontend with NIP-07 provider, network map, and all UI changes, updated nginx configs with NIP-07 injection, updated torrc template. Copy ISO to FileBrowser builds folder. Acceptance: ISO builds successfully. Copy to /var/lib/archipelago/filebrowser/Builds/.

  • POLISH-03 — Test fresh install from new ISO. Flash the ISO to a USB drive, install on a test machine (or VM). Walk through the complete first-time experience: boot → onboard (DID + npub shown, real backup, real verification) → install an app → verify NIP-07 works in iframe → verify health monitor auto-restarts crashed container → federate with an existing node → verify file sharing and DWN sync work. Acceptance: Complete user journey works on fresh install with zero manual intervention.

  • POLISH-04 — Tag v1.1.0 release. Update version in core/archipelago/Cargo.toml and neode-ui/package.json to 1.1.0. Update CHANGELOG.md with all new features: Nostr identity in onboarding, NIP-07 iframe signing, 7-node federation tested, file sharing across nodes, DWN multi-node sync, node visualization map, health monitor fix, Tor address rotation, per-app Tor toggle. Tag v1.1.0 in git. Acceptance: Tagged release with comprehensive changelog.


Updated Milestone Summary

Date Milestone Key Deliverables
Nov 2028 v1.0.0 Production release (158 tasks)
Apr 2026 Sprint 40-41 Webhook fix, identity completion, NIP-07 signing
May 2026 Sprint 42-43 Tor rotation, per-app toggle, 4-node federation deployed
Jun 2026 Sprint 44-45 File sharing across nodes, DWN multi-node sync
Jul 2026 Sprint 46-47 Node visualization map, first-install integration tests
Aug 2026 Sprint 48-49 7-day uptime test, scale to 7 nodes
Sep 2026 v1.1.0 Full feature release — all 8 features shipped and tested

Total new tasks: 40 across 11 sprints over 6 months.


Execution Instructions

For each task in order:

  1. Find the first unchecked item
  2. Read the task description and acceptance criteria carefully
  3. Read ALL relevant source files before making changes
  4. Implement following CLAUDE.md conventions strictly
  5. For frontend changes: cd neode-ui && npm run type-check && npm run build, deploy with ./scripts/deploy-to-target.sh --live
  6. For backend changes: deploy with ./scripts/deploy-to-target.sh --live (builds on server, not macOS)
  7. Verify acceptance criteria are met
  8. Mark it done in this file
  9. Commit: type: description
  10. Move to the next unchecked task immediately

Total tasks: 158 completed (v1.0.0) + 40 new (v1.1.0) = 198 tasks across 50 sprints.