| D-46 | Where do Log Monitoring's reports and its install action go? Backend Phase 13 (2026-10-07) puts six report groups — Dashboard, Traffic, Errors, Bots, User Agents, Bandwidth, about 50 reports — in the Application panel (13.5), and makes install / enable a server-level action (13.3). Both of the frontend doc's menus are fixed (U14.4 apps, U13.4 servers) and neither has an item for them | Raised 2026-10-07. Placement only — the screens are specified. This is the largest single addition to the app panel so far, so it reads like a section of its own rather than one tab; the install action reads like a server Settings item. The reports also have no OSS counterpart to copy, since the OSS panel has no Log Monitoring screen | Bhavik to place both, since the menu orders are his decision. Nothing reordered. See FE: Log Monitoring |
| D-45 | Where do four server screens go in the fixed server menu? Phase 9 (2026-10-06, revised 2026-10-07) lists the server panel screen by screen. Most map onto the frontend doc's fixed 16-item menu, but 9.18 Docker (networks and volumes), 9.24 Panel update (update OSS on the server), 9.25 Service monitoring (on / off plus a check interval) and 9.30 PHP-FPM config have no place in it | Raised 2026-10-06. Placement only — all three are specified. Docker looks type-only, like Deployment and PHP; Panel update and Service monitoring read like Settings or Services items; PHP-FPM config sits naturally under PHP, and the new 9.29 Change server IP under Settings. Phase 9 still has no Notifications screen, which keeps half of D-37 open | Bhavik to place them, since the menu order is his decision. Nothing reordered. See FE: Server screens |
| D-44 | How is a whole colour palette made from one brand colour? Backend 12.8 (2026-10-06) lets a White label owner set a brand colour and says a colour palette is made from it. This site's Theme specifies a fixed set of shadcn/ui tokens in light and dark, chosen for contrast | Raised 2026-10-06. Conflict A palette generated at runtime from an arbitrary colour has to stay readable in both modes for a colour nobody checked. Two honest options: generate a contrast-safe scale and show the owner the result before saving, or accept the brand colour only where contrast is safe (header, buttons, accents) and keep the rest fixed — far less work, and it cannot produce an unreadable panel | Bhavik / design to pick one. The Theme page was not changed meanwhile. See FE: Control Panel & White label |
| D-43 | Where does the Control panel screen go in the fixed server menu? Backend 12.1 (2026-10-06) puts one control panel user under a server, with limits and permissions. The frontend doc's server menu order (U13.4) is fixed and has no Control Panel item | Raised 2026-10-06. Placement only — the screen itself is specified. The same shape of question as D-37 (per-server notifications) and D-40 (four app tabs) | Bhavik to place it, since the menu order is his decision. Nothing reordered. See FE: Control Panel & White label |
| D-42 | Who serves the customer-facing Control Panel, and on whose domains? Backend Phase 12 (2026-10-06) has Central serve one Control Panel app on the default manage domain and on every owner's custom domain (12.9), resolving each owner's branding per host (12.8), with automatic SSL for domains added at any time | Raised 2026-10-06. This is the first phase that needs a second signed-in surface for people with no Central account. Everything specced so far is one app, one login, one domain. Whether this is the same Next.js app with host-based routing or a separate app is a hosting and routing decision, not a documentation one — and it decides how much of Phase 10's app screens can be reused | Bhavik + whoever owns hosting. Nothing assumed: the page specs the screens and marks the paths it had to propose. See FE: Control Panel & White label |
| D-1 | How does Next.js hold the token? | V8 doc: "decided later". Project rule: httpOnly cookies. Partly answered 2026-10-03: Central issues the access + refresh token itself after all login checks (2.9), so there is no browser-side OAuth grant to drive. Still open: the response shape and where Next.js keeps the tokens | BFF: Next route handlers store access/refresh tokens in httpOnly cookies and attach the bearer server-side. The login/refresh response must return the tokens in the body |
| D-2 | Is an organization created automatically at registration? | Conflict Decided the other way by Bhavik on 2026-10-05 09:46: yes — the backend creates a user's default organization at sign-up. The backend doc's Phase 2 still says organizations are not auto-created (and V7 didn't), so the two disagree | Backend team to confirm, or ask Bhavik. The frontend follows Bhavik: there is no "create your first organization" step — the user lands straight in their default organization and can create more later. A fallback screen stays for the case where someone somehow has none. Everything else about organizations (default flag, letter avatar, delete rules) is unchanged. See Organizations, FE: Auth screens |
| D-10 | Server Details through a generic proxy or explicit endpoints? | Not designed | Generic proxy with an allow-list mapped to Central permissions, plus audit for every mutation |
| D-11 | May Central cache a few server facts (IP, OS, app count) despite R5? | Lists/dashboard need them when offline | Yes: a small, clearly-labelled cache refreshed by the status job |
| Q10 | Do V7 Git / storage connections move into each server's OSS at migration, or do users reconnect? | Parked by the backend (2026-10-03): decided later, with the migration phase. Until then the screens must handle "nothing connected yet" for a migrated user and explain it | |
| D-30 | One row, several tokens: what does "update everywhere" do? | Phase 5 (5.13, 2026-10-03) shows the same account once even when each server holds a different token, while 5.10 lets the user enter a new token once and updates all servers that have the account. So a single update could silently replace per-server tokens that were deliberately different | Ask the backend. Safest frontend behaviour: when a row covers several servers, the update modal lists the servers it will overwrite and lets the user untick any, rather than implying one shared secret |
| D-28 | Which single role does a migrated V7 member keep, when V7 let them hold several? | Phase 4 (4.4) requires one role per member, and V7 organizations, members and roles carry over. The backend doc doesn't say how several roles collapse into one | Ask Pair 1. Simplest safe rule: keep the role with the widest access, and list the changes in a migration report so owners can fix them |
| D-13 | Offer "install on your own VPS" (one-line command with a one-time key)? | Answered in two steps and now complete. Phase 8 (2026-10-06) made it one of the six ways in — install command (8.4), with the installer creating the token (8.10). Phase 9 (2026-10-06, Pair 1) finished the other half: everything after a server exists — the list, the server-level actions and every menu screen (9.1–9.30). So the "Servers phase" this question waited on is written end to end | Nothing left to decide. See FE: Add a server, FE: Server screens |
| D-14 | Are blueprints owned by the user (V7) or the organization (navigation)? | Conflict | Organization |
| D-15 | Who installs and licenses WP Toolkit on servers? | OSS says "installed by Central". No flow exists | Needs a product decision (part of a paid add-on?) |
| D-16 | Global search scope, given R5? | V7 search was disabled | Central-owned resources only in the first release |
| D-18 | Organization in page URLs (/o/:slug/…) or a cookie? | Shareable links vs simplicity | Cookie + switcher first. Revisit if deep links between members matter |
| D-19 | Can OSS be installed on a live V7 server and adopt its sites? | Not documented or tested | Test on a copy of a real V7 server before planning migration |
| D-20 | Which pair builds which frontend phase? | R4 splits backend phases only. Backend side is now split (2026-10-03): backend Phase 4 (Organization & Members) is Pair 1's, Pair 2 continues with Phase 5 (Integrations). The frontend split is still not agreed | Agree with Pair 1 before Phase 0. Simplest: each frontend pair follows its own backend pair's phases |
| D-21 | Minimum supported OSS version for connect | No version policy | Set it in the backend config. Refuse below it |
| D-22 | Currency and tax rules for V8 | V7: USD + INR conversion. Phase 7 (2026-10-03) says "tax added"; Phase 6 (2026-10-05) says "tax as V7 (Instamojo, or Stripe for India)" and writes every amount in $. So the trigger is now named, but there is still no currency rule, no calculation and no display rule — and the frontend must format money with a currency the API does not yet return | Business decision. Minimum the frontend needs: a currency field on every amount, and tax as a separate line in every quote |
| D-41 | Where does "ServerAvatar Lite" live in the product? Phase 8 (8.6, 2026-10-06) keeps V7's free managed server: an install script registers a server without a ServerAvatar account, attached to ServerAvatar's own accounts and plan, giving the person a limited panel login (100 apps, 100 databases; backups, Git, Fail2ban, staging, clone, workers, cloud storage and disk cleaner off). Re-installing on the same IP replaces the old one | Raised 2026-10-06. It is a product with no Central account, so it falls outside every flow this spec describes — there is nothing to add to the add-server wizard because the user never reaches Central. What may eventually be owed is a landing/marketing path and the limited panel's own login, neither of which is specified | Bhavik to say whether Central's frontend owns anything here at all. Nothing invented in the meantime. See FE: Add a server |
| D-40 | Where do four app tabs go in the fixed app menu? Backend Phase 10 (restructured 2026-10-05 12:34) lists the OSS app panel tab by tab. Twelve map onto the frontend doc's fixed app menu and three onto its type-only items, but 10.10 Databases, 10.19 Container & Compose, 10.20 Settings and 10.3 App actions (enable / disable / delete) have no place in it | Raised 2026-10-05. Placement only — the screens themselves are specified. Container & Compose is type-only and would sit with Deployment and PHP; App actions look like header actions rather than a tab; Databases and Settings have no obvious home | Bhavik to place them, since the menu order is his decision. Nothing has been reordered. See FE: Application screens |
| D-39 | Will WordPress blueprints exist in V8? Phase 10 listed WordPress blueprints among ten V7 features OSS does not have. On 2026-10-06 the backend marked Phase 10 complete and removed that list, parking the items — so the question is unanswered and FE: Application screens is now the only written record of all ten (the same situation as Q13 / Q14) | Raised 2026-10-05, still open. This spec has a whole Blueprints page, a frontend-doc section and roadmap phase 9 for it, all inherited from V7 and the demo. If the answer is no, that work disappears and D-14 (who owns a blueprint) and D-15 (WP Toolkit licensing) become moot | Decide before scheduling the Blueprints phase. The same decision covers the other nine parked items — four of them (blueprints, app tags, restore to another server, maintenance mode for all apps) are already described somewhere on this site |
| D-38 | Should a member who manages a server be told when it breaks? Backend 11.20 (final wording 2026-10-05 12:04) sends server, app and organization notifications to the organization owner only, as in V7; account events go to each user | Raised 2026-10-05. Phase 4 lets an owner give a member real access to a server, but a failed backup, a failed SSL renewal or a service going down is reported only to the owner — so the person who can fix it is not told. V7 behaved the same way, so this is "no change" rather than a regression | Product decision. If it stays owner-only, the notifications page needs an honest empty state for members, and the per-server channel screen is an owner tool. See FE: Notifications & mail |
| D-37 | Where does the per-server Notifications screen go? Backend 11.7 (2026-10-05) puts the per-server channel attachment and its event-group ticks on "Server → Notifications". The frontend's server menu order is fixed (Bhavik: Dashboard, Applications, Databases, System Users, Firewall, Cron Jobs, Fail2ban, System Logs, Services, PHP, Node.js, Settings, Disk Cleaner, Backups, Activity Log, Server Sync, + Integrations) and contains no Notifications item | Raised 2026-10-05, half answered 2026-10-07. Only a placement question, not a rules question. The alert limits are now settled: Phase 9's new 9.28 Server alerts gives them a home in the server panel, so they are no longer part of this question. What is left is the channels screen of 11.7, which Phase 9's menu still does not contain | Bhavik to choose for the channels only: add Notifications to the server menu, or fold it into Server → Settings next to the alert limits. Nothing else changes either way. See FE: Notifications & mail §C |
| D-36 | Can users create managed servers? Backend 6.9 specifies the creation flow (credit check of at least one month's price, trial-mode size limits). Bhavik decided on 2026-10-05 06:19 that they cannot — the add-server wizard has no "Managed server" choice and no managed cost preview anywhere | A frontend product decision against a written backend rule, like D-27. It only removes a screen; everything about existing managed servers (hourly billing, usage, delete) is unaffected, so nothing else in the spec changes | Backend team to confirm the removal or ask Bhavik. Until then the frontend builds no creation screen and 6.9 stays documented but unbuilt. See FE: Billing screens §D, Servers |
| D-35 | What happens on the managed-server expire date when the server's panel can't be reached? 6.12 (2026-10-05) splits the outcome by content: servers with apps or databases are powered off, servers with none are deleted that day, and Central asks each server's OSS panel to find out | Raised 2026-10-05. An unreachable panel means Central cannot tell the two apart, and the two outcomes are "recoverable" and "gone for good" | Backend to say which way it fails. Safe default: treat an unknown server as having content (power off, don't delete), and show the user that the check didn't complete |
| D-33 | After a trial, may the user choose the Free plan? 7.6 (2026-10-05) says that when the trial ends the user must pick a paid plan to continue, but the admin's starting catalogue includes Free $0 (1 app) | Raised 2026-10-05. The trial-end gate is a blocking screen, so the frontend has to know whether to show the whole catalogue or only paid plans — and whether a Free row that cannot be selected should be hidden or shown disabled | Say it explicitly in the doc. Simplest reading: Free is selectable only for accounts that never had a trial; then the gate shows paid plans and explains why Free is not offered |
| D-34 | What happens when the admin lowers a limit below what a user already uses? 7.18 (2026-10-05) lets the admin turn a feature off or lower a limit, applying at the user's next renewal, and states no check. 7.8 blocks the same move when the user asks for it while usage is over the limit | Raised 2026-10-05. At renewal a user could end up with 40 servers on a 25-server plan. The frontend can warn in advance, but it cannot invent what the backend does at that renewal — refuse the renewal, renew anyway, or block actions until the user removes servers | Backend to state the renewal behaviour. The admin editor should also show how many users would be over the new limit before Save |
| D-23 | Out-of-scope V7 features (affiliate, referral, support tickets, AI chat, white-label (no longer out of scope — backend Phase 12, 2026-10-06), managed services, InsightHub (renamed Log Monitoring in V8 — no longer out of scope either: backend Phase 13, 2026-10-07), self-hosted licences (renamed Reseller panel)): which come back, when? | V8 doc: "their own phases" — and two of them now have phases: White label (12) and Log Monitoring (13). The rest are still unscheduled | List the remaining ones on the roadmap after launch. See FE: Control Panel & White label, FE: Log Monitoring |
| D-24 | Where is this documentation hosted for good? | doc.nip.io can't resolve to our server | See Hosting |
| D-26 | Sign-up/login must match ServerAvatar v7 exactly (Bhavik 2026-10-03). The backend doc differs: account inactive until email verified (v7: active + logged in right away), no about-you step, invite accept, forgot-password wording | Backend team to align Phase 2 with v7, or confirm the differences with Bhavik | |
| D-27 | Integrations (cloud providers, Git, backup storage) are account level (Bhavik 2026-10-03 09:54, frontend doc §3 Integrations). Both backend docs store cloud providers per organization — Pair 1 copied Pair 2's Phase 5 on 2026-10-03 11:25, so the organization-level rule is now stated twice | Backend team to move providers to account level, or confirm the difference with Bhavik. This is the one open difference that changes data ownership, so it should be settled before either side builds | |