#Open questions & decisions
Only questions that are still unresolved after inspecting V8, sa-central-api-2, V7, OSS and the demo. Each has a recommendation, so it can be answered quickly.
#Carried over from the V8 doc
| ID | Question | Recommendation |
|---|---|---|
| Q3 | What does Central show when a panel is offline? | Server stays listed with "offline · last seen". Details show the unreachable state with retry. Dashboard counts it as offline |
| Q13 | After an automatic install, OSS registration is open until someone registers | Security, not a screen. Moved with the create-server flow to the Servers phase, and then removed from the backend doc when Phase 5 was shortened (2026-10-03) — this page is now the only written record. Until it's fixed, the create-server progress screen must not show the panel URL before Central has claimed the admin account |
| Q14 | Should Central rotate the server's Central token after the first successful call (it sits in the provider's start-up script)? | Possibly a "key rotated" state on the server record. Moved to the Servers phase, then removed from the backend doc with the Phase 5 clean-up (2026-10-03) — kept here so it isn't lost. No screen yet |
| PHPStan/Larastan vs R3 | Answered 2026-10-08 — new Phase 1 step 1.11: Pint and PHPStan (Larastan) are installed, and every task must pass Pint + PHPStan + Pest before it is done. So the 2026-10-03 "skipped for now" is reversed and R3's code standards are met. Backend-side either way; the frontend keeps ESLint + Prettier, and the backend's gate is a useful precedent for ours | |
Answered 2026-10-08 — new Phase 1 step 1.10. The oldest question on this site now has an owner, a phase and a method: i18n is set up in Phase 1 by Pair 2. All user-facing API texts — errors, validation, emails, notifications — come from lang/ keys, never hardcoded English, and a middleware reads Accept-Language and sets the language, falling back to English. It answers the ask differently than proposed: instead of returning type + params for the frontend to translate, the backend translates server-side. Simpler for us, with one obligation — the BFF must set Accept-Language itself on every call, because a server-side fetch carries no browser headers. Two gaps remain: which languages the backend will offer is "decided later" (we spec eight), and there is still no profile language field. Original question: who sets up translations and language detection, and in which phase? | Frontend side is already decided: next-intl, no language in the address (same paths in every language, locale from a cookie — Bhavik, 2026-10-05), 8 locales, keys in messages/*.json (frontend Phase 0). What the frontend needs from the backend: (a) accept and honour Accept-Language on every API call, (b) return error/notification type + params, not English sentences, so they can be translated, (c) a language field on the profile. If the backend cannot translate its own messages yet, the frontend maps known error codes to its own keys. See Internationalization |
#Answered by the backend
D-62 answered (Pair 1, 2026-10-16): the admin's role + permissions (view/manage, incl. tabs and actions) now come with GET /admin/menu — the frontend can hide in-page buttons again. See Admin screens.
D-27 resolved by Bhavik (2026-10-07 09:16): Integrations and Backup Storage are organization-level pages in the main sidebar, not Account/user-menu pages. B5.1 now implements the organization-scoped list; no data-ownership decision remains open.
| ID | Question | Answer |
|---|---|---|
| Q1 | Which exact server fields does Central store? | Answered 2026-10-06 (Phase 8, 8.11) — close to what this site proposed. Central keeps the link record (organization, creator, name, hostname, how it was created, cloud details, managed link, stack, status, panel URL, token, last seen) plus a one-time copy from OSS at connect: hostname, public IP, OS, OSS version, stack, CPU, RAM, disk, app count. Name and hostname both start as the OSS hostname; everything else stays in OSS. The backend removed Q1 from its own list. Note the word "one-time": those cached facts can go stale, so a screen either labels them "at connect" or reads live — which is why Q3 still matters. See FE: Add a server |
| Q2 | How does the OSS key reach Central: pasted, or sent by the installer? | Answered 2026-10-06 (Phase 8, 8.10): both, and which one depends on the way in. Narrowed the same day: for four ways (own cloud account, managed, root-password install, install command) the installer creates the token and saves it in both OSS and Central automatically; only connect an existing OSS panel asks the user to paste it; and the free ServerAvatar Lite server has no token at all, because 8.6 was corrected to say OSS is not installed on it. Stored encrypted, never shown or logged — so no screen ever offers to view a server's token. Exactly the answer this site recommended |
| D-7 | Permission levels: boolean (V7) or none/view/manage? | Answered 2026-10-03 (Phase 4, 4.5): view / manage, as recommended — so Central lines up with the OSS catalog. Parent permissions are ticked automatically. V7 grants migrate as "granted → manage". Completed 2026-10-08 (4.9–4.11): the names are published — 37 keys, manage includes delete, full parent rules, a seeder that also feeds the Control Panel's tick-list (12.3), and a V7 mapping that never reduces access. Build the matrix from the API catalog endpoint, which is still the missing piece. See FE: Permissions & role matrix, Roles & permissions |
| D-8 | Keep V7 shared servers (share one server with a person)? | Answered 2026-10-03 (Phase 4, 4.6) — against our recommendation: sharing stays. One server, one person, through an accepted invite; the shared user can never create, delete or share it; V7 shares carry over at migration. In scope for the first release. See FE: Organization & Members |
| D-9 | Must existing users accept an invitation? | Answered 2026-10-03 (Phase 4, 4.3): yes, every invite must be accepted, including by existing users, as recommended. Links expire after 7 days; invites can be resent or cancelled. See Members |
| D-25 | When will the Organization & Members rules be published? | Answered 2026-10-03 09:39: Pair 1 published Phase 4 — Organization & Members, requirements complete (organizations, invites, members, roles, share server, ownership transfer, activity log). Gap closed. See FE: Organization & Members |
| Q9 | Git / Google Drive: one-click login (V7) → token / service account (V8)? | Answered 2026-10-03: accepted. Git uses an access token or app password, Google Drive a service account, as in OSS. Consequence for the frontend: no OAuth button on any integration screen |
| Q11 | Dropbox backup destination | Skipped for now (2026-10-03): not supported in Phase 5. Not in the storage picker; V7 Dropbox users need a message and an alternative. Revisit later |
| Q12 | Hostinger: include it as a provider? | Answered 2026-10-03: no. In V7 Hostinger is not a connectable provider — no API, no connect form, no create-server. V7 only detects a Hostinger IP when a user adds an existing server, and then removes Hostinger's pre-installed Apache/MySQL before installing. So it is not part of Integrations; it belongs to the Servers phase (existing-server install). See Providers, Servers |
| D-3 | Does the subscription belong to the user or the organization? | Answered 2026-10-03 (Phase 7, 7.3): the OWNER. One plan per owner, and its limits count across all that owner's organizations — the V7 model. So migration stays simple, and a member of someone else's organization has no plan of their own. See Subscriptions, FE: Plans & subscription |
| D-4 | Keep the prepaid wallet / credits? Auto-renew from credit? Lifetime? Legacy server-based plans? | Answered 2026-10-03 (Phase 7): plans are paid from credit (tax added, saved as a charge); auto-renew takes credit on the last day; a change returns unused days as credit; lifetime owners keep their plan and extra servers (whether new users can buy lifetime is parked — and on 2026-10-05 lifetime installments, V7's 1-or-3-payment option, were parked with it, so migrated owners can be mid-installment with no V8 flow); legacy per-server plans keep working with an option to convert. Completed 2026-10-05 (Phase 6): the wallet keeps paid / free / promo credits (promo expire), V7's server credits are dropped into paid credits at migration, and credit is bought through a gateway top-up. See Billing, FE: Billing screens |
| D-6 | Do application limits still apply? | Answered 2026-10-03 (Phase 7): yes. Plans carry server and app limits, the plan page shows used vs allowed, Central checks the plan before an action, and a downgrade is blocked while usage is over the new limits. How usage is counted across organizations is not described — the frontend shows the API's numbers |
| D-29 | How does a V7 OAuth provider account become a V8 token account at migration? | Answered 2026-10-03: Vultr, Hetzner and Lightsail accounts move as they are; DigitalOcean and Linode arrive needing the user to paste an API token once — which is the "Needs new token" state (5.4), exactly as the frontend proposed. See Providers, FE: Integrations |
| D-5 | Which payment gateway(s) are authoritative? | Answered 2026-10-05 (Phase 6, 6.1): all three V7 gateways stay — Stripe, PayPal and Instamojo. Each has its own on/off switch, test/live mode and keys (read from the database until the admin panel exists), and the user sees only the enabled ones. Stripe is the only one that saves a card and drives auto-recharge (6.5). Consequence for the frontend: the gateway choice is built from the API and no gateway is named in the code. See FE: Billing screens, Billing |
| D-31 | Does the plan expiry flow delete a plan's servers, or only remove them from Central? | Answered 2026-10-05 (7.12): both — it depends on the server type. At the warning day (default −7) managed servers are powered off at the provider; at the lock day (default −15) managed servers are deleted at the provider, while self-managed servers are only removed from Central and are not touched at the provider. So Pair 1's "power-off and deletion" wording and Pair 2's "removed from Central" were each describing one half. The frontend must name the servers and the outcome per type. See FE: Plans & subscription |
| D-32 | Does the "+3 servers per payment" bonus survive dynamic plans? | Answered 2026-10-05, then reconciled 2026-10-06 — and the two answers agree. Pair 2 removed "+3 to the server limit" because the plan carries the server limit. Pair 1 then clarified that V7's bonus belongs to a different counter: the managed-server limit (V7 users.server_limit). So plan-billed servers follow the plan limit with no bonus, while a separate managed-server limit starts from an admin setting (default 1, 10 for redeem-code signups), grows +3 per successful payment including auto-recharge, counts managed servers only, and is checked only for trial and cloud-hosting accounts. Disagreed for three hours, then settled — 2026-10-06 12:03. V8 requirement Pair 1 kept the bonus on a separate managed-server limit and recorded the split on purpose; Pair 2's copy still called it dropped. Pair 2 has now adopted Pair 1's wording in full, so 6.4 (+3 per payment, including auto-recharge) and 6.9 (limit for trial and cloud-hosting accounts, admin setting, default 1 / 10 for redeem-code signups, managed servers only) are identical in both docs. This site had followed Pair 1 throughout, so nothing had to change. Frontend consequence: still nothing to show — Bhavik decided users cannot create managed servers (D-36), so the only limit a user ever meets is the plan's. See FE: Billing screens, Servers |
| D-17 | Where do server alerts come from, given OSS has no alerts API? | Answered 2026-10-05 (Phase 11): Central asks — OSS never pushes. Two mechanisms: Central reports the actions it did itself right after OSS answers, following long ones with a background job (11.11); and scheduled jobs poll existing OSS APIs for backups, SSL, auto-deploys, live metrics, services and health (11.12), with how often set by the admin. Alerts compare live metrics with limits the user sets per server (11.13 — V7 defaults, load based on the core count) and carry the top processes; each is sent once until fixed, then a "back to normal" (11.14). This is option (a) from the recommendation. Note what is not covered by design: work done directly in the OSS panel is not notified. See FE: Notifications & mail, Notifications |
| D-12 | How does Central run the OSS installer on a new VPS? | Answered 2026-10-03 (Phase 5): a start-up script (cloud-init / user data) passed to the provider at create time runs CENTRAL_TOKEN=<token> bash install.sh --stack=<stack> from a pinned OSS release; a background job then waits for the IP, polls the panel's health and sets Ready, or Failed with a reason. No SSH, no stored root password — as recommended. See Providers, FE: Integrations |
#New decisions needed
| ID | Question | Why it's open | Recommendation |
|---|---|---|---|
| D-65 Conflict | Does Share server need Accept? | Pair 2 (2026-10-26, Jayshree, v7 parity) built 4.6 with no accept: existing accounts get access at once, new emails get a sign-up link; no designation field. Bhavik's settled decision: email + designation + per-server permissions + accept | Bhavik decides (pending 98); screens follow the backend meanwhile |
| D-64 ✅ Decided (Bhavik 2026-10-16) | Inject the admin's custom header/footer code as-is? No. | Pair 1 B17.17 stores free HTML/script in header / footer (max 20,000 chars) and returns it publicly (API97), meant for every page incl. login. Rendering it would let anyone with site-settings manage — or anyone who takes over such an account — run script in every user's browser, including on the login page (password and 2FA codes typed there, session cookies, account takeover) | Decision: the frontend never renders header / footer on any page. Integrations come from an allow-list of known snippets built into the frontend (Google Analytics from the existing analytics ID first; chat widgets later as provider + ID fields, each a fixed template with a validated ID). No third-party script on sign-in pages (login, register, 2FA, password reset, invitations) or the admin panel. Strict Content-Security-Policy (no unsafe-inline / unsafe-eval, nonce per request, only the allow-listed domains). Backend ask (Pair 1): replace the free-text fields with structured integration fields, audit-log every change, require 2FA for admins with site-settings manage. Rejected: as-is + CSP (a CSP that lets admin script run cannot also stop it), and sanitizing (silently changes what the admin saved). See FE: Admin panel → Site settings |
| D-63 Conflict | Deleted servers + restore (admin and user)? | Pair 1 (2026-10-16) added an admin tab "Deleted servers (with restore)" under a user's organization. 2026-10-23: Pair 2 built user-side 9.6 — owner-only Deleted servers list, Restore, Delete permanently. 2026-10-26: Pair 1 built the admin Restore (API153) for an organization's deleted servers. Bhavik's rule: Deleted servers + Restore are not in V8 | Bhavik decides; until then no screen for it |
| D-60 Conflict | Do invitations still need Accept? | Pair 1 (2026-10-15, Vishal, "as v7") replaced invitations with Add members: existing accounts join at once, new emails become pending members joined on sign-up; no accept/decline, invitation APIs removed. Bhavik's final decision D4 says every invite must be Accepted, including existing users | Bhavik decides: keep D4 (ask Pair 1 to restore Accept) or accept the v7 model (then update U3/U6 flows; D-58 is moot) |
| D-61 Conflict | Is ownership transfer in V8? | Pair 1 (2026-10-15, Vishal) removed it: "Not in v8. The creator stays the owner." Bhavik settled on 2026-10-05 that transfer ownership + leave organization are kept | Bhavik decides: keep transfer (ask Pair 1 to restore) or drop it from U3 |
| D-59 | Should email verification for adding a server be checked only in the frontend? | Pair 2 (2026-10-15, Jayshree) removed the user/owner verified-email check from API65 (install command); "checked by the frontend". Backend 8.8 / Pair 1 2.2 still list creating a server as a verified-email action. A UI check can be bypassed by calling the API directly, so unverified (possibly fake) accounts could create servers | Keep a server-side check (as V7 and Pair 1 2.2). Frontend still shows the friendly block first |
| D-58 (moot if D-60 accepts the backend change) | May an unverified account accept an organization invitation in the app? | Pair 1 (2026-10-15, Vishal) removed the verified-email check from organization routes except ownership transfer. In-app Accept (32a) matches by account email only, so an unverified sign-up using someone else's address could accept their invitation. Backend says "guarded by the frontend" — a UI check can be bypassed by calling the API. Details | Backend requires a verified email for in-app Accept (or the email-link token). Frontend hides Accept/Decline for unverified users and shows Verify + Resend, as a UI nicety only |
| D-51 | Where do WP Toolkit's screens go? Backend Phase 16 (2026-10-08) puts the largest group of controls in the app panel on each WordPress app — core updates, plugins and themes, tools, debug and site settings, security, maintenance mode and Object Cache Pro — and the frontend doc's app menu is fixed (U14.4) with no item for any of it | Raised 2026-10-08, and the seventh of this family (D-40, D-43, D-45, D-46, D-47, D-48). Two wrinkles: maintenance mode may not stay in this add-on (the backend is deciding whether it becomes free, as in V7), so it should be placed in a way that lets it move; and it is add-on-gated, so whatever place it gets must have a sensible empty state for users who have not bought it | Bhavik to place the group. Nothing reordered. See FE: WP Toolkit |
| D-50 | What shape is the admin panel? Narrowed on 2026-10-08 08:00 — the navigation is now specified, the frame is not. 17.2 publishes fifteen admin permission groups (Dashboard · User management · Organizations · Servers · Premium Hosting Care · Alerts · Referrals · Codes · DNS · Site settings · Integrations · Plans · Settings · Debugging · Add-ons) in the admin's own tables and seeder, and 17.3 builds the sidebar from them — title, Lucide icon, url, order, filtered to what the role can view. What is still open is where the admin area lives: a section of the same app or its own layout, and where an admin with a single permission lands. 17.1 settles that an admin is an ordinary account marked administrator, so there is no second login | Raised 2026-10-08. Two facts make the shell a real decision rather than a detail: the sidebar is built from the admin's role (17.3), so it is data and cannot be hard-coded, and every route checks its own permission (17.2) — including the three V7 left open. A role with one permission must still land somewhere sensible, so "the first thing you can see" replaces a fixed dashboard | Bhavik to settle the shell now that the pages have rules — the frontend doc's admin sections are still proposals. See FE: Admin panel |
| D-52 | Who may manage blueprints, backup storage and the plan page? Backend 4.9 (2026-10-08) publishes the whole permission list — 37 keys — and none of them covers these three screens. Blueprints live in Central (16.7) and have their own module; Backup Storage is an organization-level page in its own right (Bhavik, 2026-10-07 09:16); and the only billing key, organization.usage-summary (was organization.usage-summary, renamed 2026-10-17), is owner only, so nothing says whether a member can even view the plan | Raised 2026-10-08. The list is otherwise complete and careful — it names keys for Docker, containers and app settings — so three missing areas read as an oversight rather than a decision. Until it is settled these pages are specced owner-only, which is the safe reading and probably not the intended one: a team where only the owner can look at a blueprint is not how V7 worked | Backend to add the keys, or say the three areas are owner-only on purpose. See FE: Permissions & role matrix, Blueprints |
| D-53 | Should one server key really cover fourteen actions, including delete, resize and change IP? 4.9 puts the server list, page, dashboard, settings, power, resize, delete, disconnect, alerts, change IP, service monitoring, default page, panel update and sync behind a single key. So a role that may rename a server may also destroy it | Raised 2026-10-08. V7 was no finer, so this is inherited rather than new — but V8 added resize, change IP and panel update to the same tick, and those are exactly the actions an owner would want to withhold. This spec follows the doc and keeps one key; the consequence is that the permission layer will not protect anyone from the destructive actions, so U13's TYPE-TO-CONFIRM rule carries the whole weight | Backend to say whether a server.delete split is wanted. Nothing invented meanwhile. See FE: Permissions & role matrix |
| Raised and answered within the hour on 2026-10-08. When a user has both a Tolt affiliate code and a referral code, both count — they are separate rewards (18.12, Jayshree): the affiliate earns commission in Tolt, the referral credits are given as normal, which is already V7's behaviour today. The question existed because 18.12 first read "only one counts, which one to confirm"; the confirmation reversed it. Consequence worth keeping: the frontend doc's referral rule "affiliate code wins" is now wrong — it described V7's built-in affiliate competing with a referral, and that system is gone, so nothing competes. Reported for the flow doc, not changed here. See FE: Referral & Affiliate | |||
| D-55 | Who owns the navigation order and the page paths — the backend's seeder or the agreed menus? Backend 4.11 (2026-10-08 08:00) gives every permission entry a title, Lucide icon name, url, order (decimals allowed) and parent group, and says the sidebar is built from them: the items the role can view, sorted by order. It adds that changing an icon, link or order means editing the seeder and deploying. The frontend doc, meanwhile, fixes the main sidebar order, the server-panel menu (U13.4), the application-panel menu (U14.4) and a page-paths map | Raised 2026-10-08. Conflict The two are not really arguing about content — only about who holds the sequence. But the consequence is concrete: if the seeder's order or urls differ from the agreed menus, the product will not match the spec and the frontend cannot fix it. Two smaller unknowns ride along: whether the server and application panel menus are part of "the sidebar" at all (they are lists inside a server), and whether the seeder's urls carry a language prefix — they must not, since paths are identical in every language with the locale from a cookie | The practical ask is small: write the seeder's order and urls from the agreed menus, and treat those menus as the source. Nothing on this site assumes it can reorder navigation meanwhile. See FE: Permissions & role matrix, Navigation structure |
Yes — a new user can pick a plan before verifying. Raised and closed on 2026-10-09. The backend settled 2.2 / 2.3 / 2.11 on the V7 flow (Vishal): an unverified user can log in, refresh and use the panel, and only four actions need a verified email — sending or resending an invitation, ownership transfer (4.7), creating a server (8.8) and promo credits (Phase 7). The plan page is not among them, so Bhavik's "choose a plan straight after sign-up" works as intended, and the verification banner is a reminder rather than a gate. email_verified comes back on login, register and the current user, so the banner reads a field instead of guessing. Original question kept below for the record | Since 2026-10-09 sign-up returns tokens like login (2.1, Vishal), so the user lands in the app signed in — but every protected endpoint answers email_not_verified until they confirm their address. Bhavik's rule (2026-10-09) is that a new user chooses a plan straight after sign-up at /billing/plan | Raised 2026-10-09. Open question These two rules meet at the first screen a new user sees. If the plan list and the payment are protected like everything else, the "choose a plan" step cannot run until the inbox is checked — so the real first screen is verify your email, and the plan choice comes after. If instead plans are readable while unverified, the step works as intended. Both are defensible; only one can be built, and the difference is the entire shape of the first five minutes of a new account. Narrowed 2026-10-09: it only ever bites users who sign up on their own. Someone arriving through an invite now joins automatically and lands already verified (4.3), so they never meet the unverified state at all — which means this question is about the self-serve sign-up path alone | |
| D-56 | The backend still specifies a trial that V8 does not have. Bhavik removed the trial on 2026-10-09: no trial, no banners, and a new user picks a plan immediately at /billing/plan. The backend doc still carries trial rules in 7.6 (trial of admin-set length, ending in a must-buy gate), 7.1 (trial on / off per plan), 6.9 (trial-mode server limits), 6.13 (a trial account leaving negative balance) and 17.19 (an admin trial mode setting) | Raised 2026-10-09. Conflict The user-facing half is settled — the frontend follows Bhavik and builds no trial anywhere. What is genuinely unresolved is the admin half: 7.1 and 17.19 are settings screens, so an admin may still be offered a per-plan trial switch and a global trial mode that can never affect anybody. Building controls that do nothing is worse than omitting them, so this needs a straight answer rather than a guess. Also unstated: whether the new sign-up step offers the Free plan (see D-33) | Backend to drop the trial rules, or say they stay as dormant admin settings. Nothing user-facing is built either way. See FE: Plans & subscription 2026-10-17: Pair 1 built an admin Trial mode on/off setting (API106–107) — frontend does not build it. |
| D-49 | Are a user's extra servers counted when they downgrade? Extra servers themselves are settled — Jayshree confirmed them on 2026-10-08, so the "are they even agreed?" half of this question is closed and both docs now carry the rule (7.21 and 7.3). What remains is the original reading problem. Backend 7.21 replaces "free forever" with extra servers: the admin grants 0, 1, 2…, the server limit becomes plan + extras, and the extras stay through a plan change. It then says they are not counted in downgrade checks (7.8) | Raised 2026-10-08. The sentence reads two ways and they give different screens. Either the check ignores the extras — so someone whose servers only fit because of extras is blocked from downgrading, which is harsh and probably unintended — or it just means the extras are not recalculated and carry over, which is what the rest of 7.21 implies. The blocking message differs either way, so nothing is written yet | Backend to say which. Meanwhile the usage bar shows plan + extras as two parts, since a single total matches no plan and invites support tickets. See FE: Plans & subscription |
| D-48 | Where does the Reseller panel page live, and where does Install start? Backend Phase 15 (2026-10-07) gives the add-on a page of its own — licence key, activated domain, install status, version — and an Install that picks a server and a domain. Neither the add-ons area nor the fixed server menu has a place for either | Raised 2026-10-07. Placement only, and the sixth of this family (D-40, D-43, D-45, D-46, D-47). Note the backend marks the install method itself as not final — Git app now, possibly a Docker image later — and the two differ in how the install looks to the user, so the progress screen should not be built around either yet | Bhavik to place both. Nothing reordered. See FE: Reseller panel |
| D-47 | Where does Premium Hosting Care's per-app monitoring switch go, and where does its status show? Backend 14.6 (2026-10-07) gives each app a real on / off switch and a status — code, response time, up / down / SSL error, checked every 7 minutes from outside — but the frontend doc's app menu is fixed (U14.4) and has no item for either | Raised 2026-10-07. Placement only. Worth noting what makes it unusual: it is the only app screen that does not read through the OSS panel, so it keeps working when the panel is unreachable — and it is the one place a user sees their site as the internet sees it. The switch is also the opposite of Log Monitoring, which deliberately has none (13.4) | Bhavik to place both, since the menu order is his decision. Nothing reordered. See FE: Premium Hosting Care |
| 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. Narrowed again 2026-10-08, when auth changed from Passport to Sanctum: 1.4 specifies Bearer API tokens only and explicitly no SPA cookie / stateful mode, which removes the one competing option — so the BFF is not a preference any more, it is what is left. And handed over the same day: Phase 1's "not in this phase" line was reworded from "decided later" to "decided by the frontend pair" — so this is our decision to take, not a question waiting on the backend. Answered in substance on 2026-10-09, when Phase 2 was built: the login response returns tokens in the body (two_factor_required: false + tokens + user + organizations, or true + a challenge_token), which is exactly what the BFF asked for. Two consequences the frontend must honour: nothing is signed in until 2FA passes, so the BFF carries only the challenge and sets no session cookie until the end; and the refresh token is rotated on every use with reuse revoking the whole login chain, so refresh must be serialised through one in-flight promise and never auto-retried. Only one detail is left: no expires_in-style field is named in the response shape Open question Still open: the response shape and where Next.js keeps the tokens. And a new consequence: the refresh token is Central's own code (Sanctum has none) and lands in Phase 2, so it is being designed now | 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? | Answered 2026-10-08 — backend Phase 16. Central installs and enables it automatically when the add-on is bought, on every server the owner has and on servers added later, keeping it updated (16.4); the licence is checked before every command, by server IP (16.9, the same mechanism as Log Monitoring's 13.2). And the product half is answered too: it is a paid add-on, bought per account, recurring, covering all the owner's WordPress apps (16.1) | Nothing left to decide. There is no install screen — see FE: WP Toolkit |
| 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 B6.3/API42 now settles wallet currency as USD and returns exact string balances. Payment currency/conversion, tax calculation and quote display remain open | 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 |
| Answered 2026-10-08 — yes, backend Phase 16 (16.7). Blueprints are saved sets of plugins and themes, kept in Central, applied when a WordPress app is created, with V7's copied over at migration — and being in Central matches Bhavik's 2026-10-06 decision, so nothing is in dispute. Two caveats: the scope is narrower than this site's Blueprints page (plugins and themes at creation, not V7's cleanup options, locale and permalinks, and not a run against an existing site), and they are now part of a paid add-on. See FE: WP Toolkit. Original question: 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, unlike resolved 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 Update 2026-10-27: Pair 1 has built managed-server creation (6.9 / 8.2 Step 1: owner's paid credits ≥ one month, verified email, no managed-server limit). Still open — Bhavik to decide (pending entry 101). |
| 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 |
| Moot since 2026-10-09 — there is no "after a trial". Bhavik removed the trial from V8, so the trial-end gate this question was about does not exist. Original question: after a trial, may the user choose the Free plan? 7.6 said the user must pick a paid plan, while the catalogue includes Free $0 | The question does come back in a new form, though, and it is not answered: the sign-up Choose a plan step (/billing/plan) faces the same catalogue, so whether Free appears there — and whether a brand-new account may simply take it and never pay — is unstated Open question. Smaller scope than before, because there is no "had a trial" history to check | Say whether Free is selectable at sign-up. See FE: Plans & subscription | |
| 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 (now Premium Hosting Care — backend Phase 14, 2026-10-07), InsightHub (renamed Log Monitoring in V8 — backend Phase 13, 2026-10-07), self-hosted licences (now the Reseller panel — backend Phase 15, 2026-10-07)): which come back, when? | V8 doc: "their own phases" — and four of them now have phases: White label (12), Log Monitoring (13), the managed-services pack as Premium Hosting Care (14) and self-hosted licences as the Reseller panel (15). All four add-ons named in 7.26 are now written — and on 2026-10-08 the last two non-add-ons resolved too: affiliate / referral has backend Phase 18 (referral in Central, affiliate in Tolt, so no affiliate screen here), and support tickets are cancelled outright — not in V8. What is still unscheduled: only the AI assistant | List the AI assistant on the roadmap after launch. See FE: Control Panel & White label, FE: Log Monitoring, FE: Premium Hosting Care, FE: Reseller panel |
| 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). Four differences were listed: account inactive until the email is verified, no about-you step, invite accept, forgot-password wording | Three of the four are now settled, two of them today. ✅ The sign-up state is resolved the frontend's way (2026-10-09, Vishal), and in two steps: first register began returning tokens like login, then 2.2 / 2.3 / 2.11 were rewritten to the V7 flow outright — an unverified user can log in and use the panel, with only four named actions needing a verified address (invitations, ownership transfer, creating a server, promo credits). The backend's old "account stays inactive until verified" is gone entirely. ✅ The about-you step is gone from sign-up (2.1, 2026-10-09) — though Bhavik's rule also covers the profile, where 3.2 still has the questions, so that half stays flagged. ✅ Invite accept went the backend's way and Bhavik agreed (every invite is accepted, including existing users). Still open: the forgot-password wording — V7 says when an email is not registered, the backend answers the same either way | Only the forgot-password wording is left. See FE: Auth screens |
#New channel routing conflict — B3.15 (2026-10-10)
Conflict Live IP-added notices now route to saved channels. Bhavik allows extra channels only for server/app events; this is account security. Keep the required security email, but confirm whether the extra saved-channel routing must be removed. No routing picker is approved. Manual Send test is independently usable. See built channel spec, pending44.
#Backend wording to reconcile
New Pair2 B2.7 summary says one active2FA method; built B3.8/B3.9 describes layered email+Authenticator setup. Keep current documented setup pending clarification. Pair2 also now flags Control Panel's separate permission list versus old shared-list wording; preserve the separate-catalog spec as a proposal, not a newly resolved Pair2 decision.
D-22 partial resolution (B6.4): charge currencies/tax behavior now published—Stripe India INR+configured tax, other Stripe untaxedUSD; PayPal untaxedUSD; Instamojo INR+tax, configured FX. Render exact server breakdown, no client tax calculation. Merchant limits/activation proof and frontend return coordination remain readiness gaps, not permission to invent APIs or live success.