#Backend doc sync & traceability
The frontend spec follows the backend team's V8 project doc. This page records which version of it the frontend spec matches, and where every backend item is covered on the frontend side.
#Source documents
| Doc | Owner | Location (published) | Last change | Used as |
|---|---|---|---|---|
| Pair 2 V8 project doc | Jayshree Patil / central-api-2 | backend-2/public/v8-central-docs-ea60c2f1c31c3c9d/project-doc.md | 2026-10-10 05:37 UTC | Primary source, and fully self-contained. It carries Phases 1–18, including Pair 1's Phase 8 and Phase 9, which it copied in on 2026-10-07 (byte-identical apart from the author label). It is the authoritative source for Phases 7, 10, 11, 12, 13, 14, 15, 16 and 18 — all nine written here first, Phase 18 — Referral & Affiliate as of 2026-10-08 07:46. Read this doc unless a phase is Pair 1's |
| Pair 1 V8 project doc | Pair 1 | backend/public/v8-central-docs-7b32cacc0936ef38/project-doc.md | 2026-10-10 03:48 UTC | Author of Phases 1, 4, 6, 8, 9 and 17. Phase 4 B4.1–B4.5/B4.7–B4.11 built and pushed to GitHub main on 2026-10-10 (e9a4210, a43e3f6). It selectively copied Pair 2's Account rules/build notes; this documentation sync does not pull or deploy code, and B3.14 is reported built by Pair 2, not verified/deployed on Pair 1. Share server/server-deletion guard remain Phase 8; transfer billing/recipient-plan guards remain Phases 6–7. Preview SMTP delivery still limited |
Latest availability: Pair2 reports provider B5.1–B5.5 pulled through cf36220; Disconnect still partial. Billing B6.1–B6.3 pushed through 2ac99ce, local/GitHub main synchronized; organization filters pulled a7aefc9.
Synced with: Pair 2 doc md5 9167cd77… · Pair 1 doc md5 54a58ca9… · checked 2026-10-28 11:19 UTC. The backend also publishes a separate API reference now — read that before building any screen.
#Traceability: backend item → frontend coverage
| Backend item | What it says | Frontend impact | Covered in |
|---|---|---|---|
| 17.4 admin activity built | Separateadmin-only filteredfeed,snapshotnames,pagination | Read-only table/filter/error/denial states;Pending59 | Admin, Audit, API |
| 17.3 menu built | Pair1 role-filtered menu,34 screens/59permissions; queue-size removed | Sidebar state/group/icon/empty/denial, destinations not assumed built;Pending58 | Admin screens, API |
| 17.2/17.2a built | Pair1 catalog60/fixedrole/staffassignments/last-managerguard | Role editor/readonly/assignment/errors;Pending56 | Admin |
| 6.5 in progress | Pair2 card/consent/daily paid-only recharge and same-payment recovery drafts | Integration states NOT ready/activated;Pending57 | Billing |
| 17.2a clarification | Admin roles view+manage, impersonation separate manage-only; Users-manage grants neither | Read-only roles/detail/assignments vs mutation controls; unbuilt, Pending55 | Admin screens, Permission matrix, Roles |
| 17.1 admin entry | Pair1 own discovery + guarded verified administrator identity built; same login; no role/sidebar/business screens | Entry eligibility, checking/identity/refusal/verification/revocation states; Pending54 | Admin screens, API, Routes |
| 6.4 Add credits local/not activated | Exact quote, hosted checkout/status/confirm/free codes; unresolved real payment deletion block | Form/review/return/status/recovery/redemption; NOT live READY; Pending53 | Billing screens, Account, API |
| 6.3 Wallet built built/pushed | Own-account USD paid/free/promo/total strings+as_of; negative-paid debt blocks deletion409 | Read-only wallet/error≠zero; debt refusal even positive total; Pending52 | Billing screens, Account, API |
| 4.1 list filters | Literal search, all/mine/invited, joined/pending; no pagination; pending has no access or acceptance token | Organization tabs/pending card/email-link helper; switcher stays joined-only. Pending51 | Organization screens, Organizations, API |
| 6.2 Billing details | Pair2 GET/PUT own-account identity built locally/not pushed; full form, optional city/tax rows, separate billing email, referenced unavailable error | Billing settings form, all states/limits/errors and no organization-role gate; payment/receipts still unbuilt. Pending50 | FE: Billing, API |
| R1 V7 functional reference only | No V7 code reuse | Frontend is new too. V7 is used only for flows/UX | Sources |
| R2 Build from V8 requirements | V8 doc wins | Every frontend page cites the backend item | this page |
| R3 Code standards | Laravel standards, Sanctum (Passport until 2026-10-08), MySQL 8.4 LTS (MariaDB until 2026-10-08), per-pair DB | Base URL = own pair's API only. Paginated lists. Ids may be char(36) UUIDs — treat every id as a string | API architecture |
| R4 Working method | Phase by phase. Changed 2026-10-08: "nothing is built by either pair yet" became "development has started, feature by feature on main" — Phase 1 is built by Pair 2, and Pair 1 takes it with a pull | Frontend phases follow backend phases. The two halves are now in different states — backend building, frontend still scaffold — so this site is a specification, not a description | Implementation phases, Overview |
| R5 Central stores minimum, OSS live | Server/app data from the OSS API | Server Details = live proxy views, offline states | Architecture, Server details |
| §2.2 Common OSS client | One client, consistent errors. Built with the Servers phase, not the Foundation phase (2026-10-03) | Frontend maps a small set of server error codes. Server Details screens cannot start before the Servers phase | Global states, Architecture |
| Phase 1 1.1–1.11 Foundation | ✅ BUILT 2026-10-08 — MySQL, Redis, Horizon, Sanctum, Telescope, CORS, mail/log, security, 1.10 translations, 1.11 Pint + PHPStan + Pest. API at /api/v1 | CORS origin = frontend URL. HTTPS + secure cookies. "Next.js login flow decided later" | FE: Foundation |
| 2.1 Register | Name, email, password ≥ 8, Turnstile, optional codes + onboarding | Register screen | FE: Auth screens |
| 2.2 Email verification | Inactive until verified, resend, 24 h | Check-inbox + verify-result screens | FE: Auth screens |
| 2.3 Login | Email + password, unverified/banned messages, token + user + organizations, login history | Login screen | FE: Auth screens |
| 2.4 Google / GitHub | Redirect → callback, auto-link, same 2FA/IP checks | OAuth buttons + callback page | FE: Auth screens |
| 2.5 Forgot / reset | 60 min link, logs out all devices | Forgot + reset screens | FE: Auth screens |
| 2.6 Invitation password | ✅ Built with B4.3, confirmed in corrected Phase 2 status (Pair 1, 2026-10-10) | Existing invitation screen; auto-join versus explicit Accept remains a conflict, not resolved by this status correction | FE: Auth screens |
| 2.7 2FA at login | Email code 10 min / 5 tries / resend, authenticator, backup code | 2FA step | FE: Auth screens |
| 2.8 IP whitelist at login | Block + approval email 24 h | IP-approval notice + result | FE: Auth screens |
| 2.9 Tokens | Bearer 15 d + refresh 30 d, rotation. Central issues both tokens itself after password → 2FA → IP checks, for email and Google/GitHub login (2026-10-03) | BFF cookies, refresh once. One login response carries both tokens; the OAuth callback is handled like a password login | FE: Auth screens, FE: Foundation |
| 2.10 Logout | Revoke current token | Logout action | FE: Auth screens |
| 2.11 Security | Rate limits, middleware | 429 handling on every auth form | FE: Auth screens |
| Phase 2 settings | Mail/Turnstile/OAuth keys from admin panel (DB until then) | Turnstile site key must come from the API, not a frontend env file Open question | FE: Auth screens |
| Phase 2 "not in this phase" | Orgs not auto-created; dropped V7 sign-up checks; migration later | Conflict D-2: Bhavik decided on 2026-10-05 09:46 that the backend creates the user's default organization at sign-up, so the frontend has no "create your first organization" screen — only a fallback for an account with none. The backend doc still says the opposite. The dropped sign-up checks need no UI | Organizations, FE: Auth screens, Open questions |
| 3.1–3.7 Profile | View, update (+ onboarding answers), change email, change password, email preferences, delete protection, delete account | Account → Profile | FE: Account screens |
| 3.8–3.13, 3.16 Security | 2FA + backup codes, Google Authenticator, IP whitelist, login history, account activity, API access, active sessions. V7 API tokens are migrated and keep working; users do not create new ones (2026-10-03) | Account → Security. The API screen is an on/off switch with no "create token" button — this answers the old Open question about a copy dialog | FE: Account screens, V7 migration |
| 3.14, 3.15, 3.17 Notifications | ✅ SectionC B3.14+B3.15 built and pushed by Pair2,2026-10-10; six channel types, no saved-count cap; publicHTTPS443; masked retained credentials; async tests with status; B3.17 later | Channel CRUD/test spec with queued/sent/recorded/failed/cancelled; no current routing/attachments API. Live IP-added notices conflict with server/app-only channel decision. Pending44 | Account, Built channels |
| Phase 3 "not in this phase" | Confirmation timer ignored. Billing, referral, support, AI later | Not built | Open questions |
| Phase 3 existing users | Profile, preferences, 2FA, IP whitelist, login history, channels and API tokens carry over from V7 | Every account screen must load pre-filled data and never invalidate a migrated API token | FE: Account screens, V7 migration |
| Phase 4 Organization & Members | Requirements complete 2026-10-08 (Pair 1), first written 2026-10-03 09:39 V8 requirement: organizations with a default and letter avatar, delete rules, invites that must be accepted (7-day links, resend, cancel), one role per member, fixed Owner + Admin and custom view / manage roles, share one server, ownership transfer, organization activity log | Built B4.1–B4.5 and B4.7–B4.11, Pair 1 (2026-10-09); B4.7 built including deletion safety; billing/recipient-plan checks wait for Phases 6–7. B4.6/server-deletion guard wait for Phase 8. Full screen spec written. Closes D-25, and answers D-7 (view/manage), D-9 (accept always) and D-8 (sharing stays — against our recommendation) | FE: Organization & Members, Organizations, Members, Roles & permissions, Audit log |
| 4.9–4.11 The permission list, parents and seeder | New 2026-10-08 (Pair 1) — the item nine pages here were waiting for. 4.9 publishes 37 keys, each with view / manage, where manage includes create, edit and delete ("no separate delete"): 6 organization (organization, .members, .roles, .activity view-only, .integrations, .billing owner-only), 14 server (one wide server key covering list, settings, power, resize, delete, disconnect, alerts, change IP, panel update and sync, plus database, system-user, firewall, fail2ban, cronjob, service incl. PHP-FPM, runtime, docker, logs, disk-cleaner, backup, notification, activity), 15 application (incl. application.settings, .environment, .container, .staging, .security) and 2 add-on (application.wp-toolkit, application.log-monitoring). 4.10 parents: each .manage includes its .view; server keys need server.view; app keys need application.view; server.view needs organization.view; application.manage also needs server.system-user.manage and server.database.manage; ticking a child ticks parents, unticking a parent unticks children, and the backend re-adds missing parents on save. 4.11 seeder (sharpened twice more, at 07:17 and 08:00): the permissions live in the seeder itself, as V7 — not a config file, synced by name + level, with labels from translation files. At 08:00 each entry also gained its menu data — title, a Lucide icon name, url, order (decimals allowed) and a parent group — and the sidebar is built from the list: the items the role can view, sorted by order, icon resolved by name with a fallback; "changing an icon, link or order = edit the seeder and deploy". Roles get permissions in the role editor, view and / or manage per permission, stored as two flags on the role ↔ permission link (as OSS); fixed Owner and Admin roles (Admin gets all but owner-only; the owner skips checks); new permissions are never auto-added to custom roles; a removed key is deleted only with prune — and the same list feeds the Control Panel's tick-list (12.3). Migration: all 92 V7 permissions mapped, the broader key where V7 was finer, never less access, with a report | New page: FE: Permissions & role matrix — the single biggest gap on this site, closed. Nine pages carried the sentence "the permission names are not published" and all nine were rewritten: Roles & permissions, Organizations, Phases, FE: Organization & Members, FE: Integrations, Missing backend, FE: Control Panel & White label, Findings and V7 migration. Four answers worth having: no separate delete fixes the matrix as three states per row, so it is a form and not a spreadsheet; 12.3 is not a second catalog — the Control Panel uses this same list, which closes an item marked unpublished; server.notification settles half of D-37, and application.settings finally names Settings as a real app area (D-40, and 14.6's home). The 08:00 sharpening is the one that reaches furthest: the sidebar is now backend data. Icons arrive as Lucide names, which matches the frontend's icon library exactly but means resolving them at runtime with a fallback — use a curated map of the names the seeder ships, not the whole set, or the bundle pays for it. And it raises D-55: the frontend doc fixes the main sidebar order, the server menu (U13.4), the app menu (U14.4) and a page-paths map, while 4.11 puts order and url in the seeder — so a mismatch would be a backend deploy to fix, not a frontend change. Flagged [!CONFLICT], nothing overwritten; the practical ask is that the seeder be written from the agreed menus. Navigation structure is marked accordingly — its badges, plan-locked treatment, active-state rule and collapse behaviour stay the frontend's, because the backend says nothing about them. Also refined: a role sets view and / or manage as two flags, not one mutually exclusive value — a three-state control is still the right rendering, but it must send both. Labels come from translation files — a real step on Q8, since the widest form in the product is translatable from the start. One warning: application.manage silently grants two server permissions, so the form must say so at the moment of ticking. Two decisions raised: D-52 — blueprints, backup storage and the plan page have no key at all; D-53 — one server key covers delete, resize and change IP, so the permission layer cannot protect anyone from them | FE: Permissions & role matrix, Roles & permissions, Missing backend, V7 migration |
| 4.1–4.2 Organizations | Creator is owner; first one is the default; letter avatar when no logo; delete is owner-only, never the default organization (made absolute by Bhavik on 2026-10-05 10:24), and not while it has servers | List + settings + danger zone; the delete button shows the blocking reason instead of failing. On the default organization it is permanently off — the default is created at sign-up (D-2) and always exists, so delete only ever applies to the extra organizations a user made | FE: Organization & Members |
| 4.3, 4.4, 4.6 Members & sharing | Invite (email, designation, role), every invite accepted, 7-day links, resend/cancel; one role per member; owner untouchable; leave; share one server by invite with no create/delete/share | Single-select role picker, pending rows with "expires in N days", shared people listed apart from members | FE: Organization & Members, Members |
| 4.5 Roles | Owner and Admin fixed; custom roles view / manage; parents ticked automatically; no delete while members hold it | Read-only system roles, auto-ticking matrix built from the published API catalog (B4.5, B4.9–B4.11 built), Delete disabled with "N members use this role" | FE: Organization & Members, Roles & permissions |
| 4.7 Ownership transfer | Built Pair 1 (2026-10-09), deletion-safety extension included. Both active/verified; own password/email + own 2FA; confirmation 10 minutes/5 failures; one pending request; owner cancel; recipient accept within 48 h; old owner Admin, defaults unchanged. Billing/recipient-plan blocks not enforced yet | Five real endpoints, separate challenges, cancel/expired/stale states; backend security blocker resolved; preview email delivery still requires verification. Pending 42 | FE: Organization & Members, Organizations |
| 4.8 Organization activity | ✅ Built Pair 1, 2026-10-09: activity-view, translated organization/invitation/member/role rows, actor name snapshots, type/action filters, newest first 10/page (max 50). Failed operations absent; transfer start/accept/cancel recorded; share hooks later | Shared account/organization table component; deletion disappears from organization history but remains in owner's account log. Published route replaces V7 guesses; no CSV/search/status promises | Audit log, FE: Organization & Members |
| Phase 5 Integrations | Requirements drafted 2026-10-03 V8 requirement: cloud providers in Central (organization level); Git accounts and backup storage live in each server's OSS with Central keeping only a note ("Option B"); create a server on a provider with automatic OSS install; organization Integrations page | Full screen spec written: provider list/connect/reconnect/disconnect, create-server wizard + live progress (Creating → Installing OSS → Ready / Failed), Git / storage modal with "add to other or all servers" and a result per server, replace-token-everywhere, remove from one or all | FE: Integrations, Providers, Servers, Server details, Phases |
| 5.5 Provider Disconnect | Partial: manage-only empty-input DELETE built Pair1;200 deleted snapshot;repeat404, prior history retained. No upstream revoke/server delete | Confirmation/results/stale Edit/Check states specced; server-usage guard+names warning not built, full feature notREADY. Pending49 | FE: Integrations, API |
| 5.4 Provider Check | ✅ Built Pair1: empty-input manage-only on-demand POST;200 Connected/Needs new token,503 unchanged,unreadable→Edit,409 stale result refused | Distinct result states; no automatic checks; shared Connect/Edit/Check limiter; history only on actual status change. Pending47 | FE: Integrations, API |
| 5.3 Provider Edit | ✅ Built Pair1,2026-10-10: manage-scoped PATCH; optional name/complete credentials; immutable provider; fresh409 conflict; no old-field changes on422/503 | Rename/replace form; omit unchanged secrets, full Lightsail pair, preserve old fields on error, reload/review on409. Successful edit activity; no failed/conflict/no-op entry | FE: Integrations, API; pending46 |
| 5.1 Cloud-provider list | ✅ Built Pair 1, 2026-10-10: scoped metadata, name search, provider/status filters, newest first 10/page max 50; integration-view; active unverified users may list | Read-only /integrations list with real API, translated labels, loading/empty/no matches/refused/error states; no secret, usage count or current validation result. Mutations B5.2–B5.5 pending. Pending entry 43 | FE: Integrations, Providers, API architecture |
| 5.2, 5.3 Named accounts + Edit | New 2026-10-03: each provider account gets a name, several accounts per provider are allowed, and Edit changes the name or pastes a new token. "Needs new token" now points at Edit | Name field in the connect modal and everywhere the account is picked; one Edit modal (token blank = keep current) replaces the separate "paste new token" dialog; the list groups by provider and shows names | FE: Integrations, Providers |
| 5.6, 5.8, 5.9 Git & storage | New / changed 2026-10-03: Git and storage accounts also get a name; the result per server applies to connect, update and remove alike; a Test button checks the account on that server | One result table reused by all three actions (never a single "saved" toast for a multi-server action, including removals); per-server Test with the last result shown on the row | FE: Integrations §C |
| Who can do it | New 2026-10-03: connect, edit, test and remove follow the organization roles from Phase 4 | Every button on the integration screens is permission-driven. The permission names are still unpublished, so checks come from the API catalog | FE: Integrations, Roles & permissions |
| 5.1, 5.4, 5.5 Cloud providers | Pasted API token for every provider — no OAuth (Lightsail: access key + secret), checked on save, encrypted; no renewal — a rejected token marks the account "Needs new token"; disconnect keeps servers. Requirements complete 2026-10-03 | One connect modal for all providers, never a redirect; "Needs new token" blocks creating servers with that account. Conflict with V7's OAuth accounts → D-29 (how they migrate) | FE: Integrations, Providers |
| 5.3 Regions & sizes | Moved out of Phase 5 → Servers phase (2026-10-03), read live when creating a server | Part of the create-server wizard, not the Integrations page | Servers, FE: Integrations §B |
| 5.13 Repos & branches | Moved out of Phase 5 → Applications phase (2026-10-03), read from the server's OSS | Account → repository → branch dependent dropdowns move to the application-from-Git flow | Server details, Phases |
| Create server (was Phase 5 B) | Moved out of Phase 5 into the Servers phase on 2026-10-03; the backend's draft is parked at the end of their Phase 5, with Q13, Q14, the Ubuntu 20.04 limit and Hostinger's pre-installed stack | Spec kept and clearly marked as Servers phase work: wizard + progress screen (Creating / Installing OSS / Ready / Failed), polling, safe to leave the page. Still answers D-12. Frontend phase 5 (Servers) now owns it | FE: Integrations §B, Servers, Providers, Phases |
| 5.5 Disconnect a provider | Changed 2026-10-03: blocked while any server was created with the account; the warning lists those servers. Allowed only when none use it | Disconnect button disabled with "Used by N servers" and the list in the dialog — replaces the earlier "servers keep running" wording | FE: Integrations, Providers |
| 5.16 Integration activity log | New 2026-10-03: every integration action (connect, edit, add to other servers, update everywhere, remove, disconnect) goes into the organization activity log with who, which account, which servers and when. Tokens and keys are never logged | Nothing new to build — but one entry can cover several servers, so render the server list inside the entry rather than one entry per server | FE: Integrations, Audit log |
| 5.13 Accounts already on the server (renumbered from 5.16) | New 2026-10-03: Central reads existing Git / storage accounts from OSS and shows them; the same account on several servers appears once; adding it to more servers needs the token pasted once | The list mixes accounts Central set up with accounts found on a panel — found ones are marked, grouped by account (not by server), and Central never claims to hold their secret | FE: Integrations §C |
| 5.6–5.15 Git & storage | Form in Central, secret pushed to chosen servers' OSS, per-server result, update everywhere, remove from one or all, repos/branches read from OSS, provider lists | Per-server modals + the organization overview. Central never shows a saved secret again | FE: Integrations, Server details |
| Phase 6 Billing: wallet, payments & managed servers (written by Pair 1, in both docs since 2026-10-05 07:32) | Requirements complete 2026-10-05 V8 requirement: gateways, billing details, wallet, top-up, cards + auto-recharge, reminder, history + receipts, managed servers charged hourly, and a negative-balance process for managed servers only (the wallet track was removed the same day) | Full screen spec written. Answers D-5 (Stripe / PayPal / Instamojo) and finishes D-4 (how credit is bought). Raises D-35 (unreachable panel on the expire date); D-31 and D-32 were raised here and both answered on 2026-10-05 | FE: Billing screens, Billing, Servers, Dashboard, V7 migration |
| 6.1 Gateway setup/list | ✅ Local Pair2/not pushed: encrypted settings + safe enabled metadata API; defaults disabled, no real credentials | Metadata-driven empty/single/multiple gateway states with visible test mode; no keys/config mutation/checkout implied. Admin setup deferred. Pending48 | Billing screens, API |
| 6.1, 6.2 Gateways & billing details | Stripe, PayPal, Instamojo, each on/off with test/live mode; the user sees only enabled gateways. Billing details (name, address, country, tax number) on the account that pays, copied onto every receipt | Gateway picker built from the API, never a hard-coded list; test mode visible to the user; one account-level billing-details form, with "new receipts only" under it | FE: Billing screens |
| 6.3, 6.4 Wallet & top-up | Paid / free / promo credits (promo expire); server credits dropped. Minimum from settings, maximum $4,000, promo not at or below the minimum, tax as V7, credit added only after the gateway confirms and only once. V7's "+3 server limit" per payment was dropped on 2026-10-05 — the server limit comes only from the plan | Three balances shown separately (only paid credit buys managed servers); promo field disabled with the reason below the minimum; "Confirming payment…" return page that never trusts the query string; the +3 effect explained on success | FE: Billing screens §A |
| 6.5, 6.6 Cards, auto-recharge, reminder | Stripe saved card; automatic charge when credits fall to the user's minimum; low-credit reminder set between $1 and $1,000 | Auto-recharge switch blocked with "Add a card first" when no card is saved; the last automatic charge and its result shown in-app, not only by email; removing the card warns that auto-recharge stops | FE: Billing screens §B |
| 6.7 History & receipts | Payments and charges in one list; a receipt for every payment with billing details and tax | One table, two row kinds (money in / money out) with a filter; a receipt link only on payment rows, never on an hourly charge | FE: Billing screens §C |
| 6.9 Create a managed server | Credit check of at least one month's price, trial-mode size limits, monthly price saved with the server | Conflict D-36 — the frontend builds no screen for this. Bhavik removed the "Managed server" choice from the add-server wizard on 2026-10-05 06:19, and no managed cost preview appears anywhere. Everything about existing managed servers is still built (6.10–6.13) | FE: Billing screens §D, Servers, Open questions |
| 6.8–6.11 Managed servers | Admin price list per provider / region / size (DigitalOcean, Vultr, Linode, Hetzner); create needs one month's price in credit (trial: a limit and only popular sizes); hourly rate = monthly ÷ (days in month × 24), full hours, paid credits only; usage per server | A second kind of server — the server list and the create wizard must show which money model a server is on. Review step shows monthly price, hourly rate and balance before Create; "not enough credit" means paid credit; the hourly rate changes between months, so it is never computed in the browser. No managed price list for AWS Lightsail, which Phase 5 does let users connect | FE: Billing screens §D, Servers, Providers |
| 6.12–6.13 Negative balance | Narrowed 2026-10-05 to managed servers only. The wallet track for plan-billed servers (days 1–15, "backups / SSL / health checks stop") was removed — "that V7 code is no longer scheduled" — and unpaid plans now belong entirely to the plan expiry flow in Phase 7. What remains: one daily process starting when paid credits reach 0 or below, with the dates worked out once and saved — reminders → due date (+4 d) → expire date (+3 d) → deletion date (+7 d), trial 2 / 2 / 4, all V7 defaults. Refined the same day: on the expire date, servers with apps or databases are powered off while servers with none are deleted that day (Central asks each server's OSS panel); the rest go on the deletion date. 6.13 expanded 2026-10-05 06:32: going back above 0 stops the process, clears the saved dates and ends trial mode — but powered-off servers are not powered on automatically | Three states, not one: due, powered off, about to be deleted. Because the dates are saved once, show the stored dates and never recount from today's balance. The expire-date split is the sharp edge — two servers in the same list meet opposite fates on one day, and the empty one is gone for good, so the warning must name which servers will be powered off and which deleted. Dropped with the wallet track: the global "wallet below $0" banner and the "paused by billing" state. The timing days are parked for an admin-settings phase, so never write a day count into a screen or a string. After a top-up the banner and every deletion date must disappear (the dates are cleared) and the plan and limits be re-read (trial mode ends) — but the success message must not imply the server is back up, because it stays off until started again. New question D-35: what happens when a panel can't be reached on the expire date | FE: Billing screens §E, FE: Plans & subscription, Servers, Dashboard |
| Phase 6 existing users | Paid, free and active promo credits, cards, auto-recharge, reminder, billing details, transactions, receipts, managed servers and their charges carry over; leftover server credits become paid credits | Every billing form opens pre-filled; no "server credits" row anywhere; the history must cope with older V7 rows; a migrated managed server already has hours used this month | FE: Billing screens, V7 migration |
| Phase 7 Plans (Subscription) | Requirements complete 2026-10-03 V8 requirement: admin-managed plans with a per-plan feature list, one plan per owner across all their organizations, paid from credit (tax added, saved as a charge), trial, change with unused days returned as credit, downgrade checks, cancel / resume, auto-renew, reminders, the V7 expiry flow (day −7 warning → day −15 servers removed from Central + account locked), coupons, plan visibility + display name, enterprise form, activity log | Full screen spec written, including the shared "may I do this?" pattern for plan guards and the locked-account state. Answers D-3 (owner, not organization), D-4 (credit wallet stays, lifetime and legacy kept) and D-6 (limits apply) | FE: Plans & subscription, Plans, Subscriptions, Billing, Audit log |
| 7.1, 7.2, 7.13, 7.14 Admin side | Create / edit / hide / archive plans; one feature list turned on-off per plan; coupons. 7.14 rewritten 2026-10-05: all plans are shown to all users, so there is no general visibility setting and no per-plan display name — a user list on a plan exists only to migrate V7 "restructured" accounts | Admin plan editor is a full page driven entirely by the API's feature list, so later phases add features without a frontend change. The plans page is now the same for everyone by default, with migrated restructured users the one exception — so the catalogue is still never cached across accounts, and the frontend shows the plan's name (no display-name fallback) | FE: Plans & subscription §A, Plans, V7 migration |
| 7.12 After expiry | Rewritten 2026-10-05 — the outcome now depends on the server type. Reminders → warning day (default −7): managed servers are powered off at the provider → lock day (default −15): managed servers are deleted at the provider, self-managed servers are only removed from Central (left running there), and the account + the owner's team members are locked. While expired, all server actions are blocked but the user can still view data, delete a server and add credit / renew | Answers D-31 — Pair 1's "power-off and deletion" and Pair 2's "removed from Central" were each describing one half. For the screens this means two dates, not one (power-off and lock), and a banner that names the servers and says which fate is which — the same pattern the managed-server overdue warning uses (6.12). The locked screen may promise "still at your provider" only for self-managed servers; a managed one is gone | FE: Plans & subscription §B, Servers, Subscriptions |
| 7.17 Price change | New 2026-10-05: when the admin changes a plan's price, users already on that plan are warned by email first and the new price starts at their next renewal | The plan page shows the price that will be charged next, not the one that was paid, with the old price struck through while a change is pending; the "not enough credit to renew" warning recalculates against the new price. The admin plan editor must say that an edited price reaches existing users at renewal | FE: Plans & subscription §B, Plans |
| System vs custom plans | New 2026-10-06: seeded system plans — Free, Newbie, Pro, Master, Business, Managed / Self Managed (migrated restructured users), Legacy per-server, Lifetime — each with a fixed key used by the backend and the migration that never changes. The admin may edit name, prices, limits, features, add-ons and visibility but cannot delete them (archive / hide only), and Free cannot even be archived. Custom plans can be deleted only if nobody has ever been on one. Re-running the seeder only adds missing plans | Nothing changes in rendering: plan names are still data, and the key is the backend's identity, not something to branch on — the one honest use is showing it in the admin list so a system plan is distinguishable from a look-alike custom one. The admin plan list needs three different disabled states: system plans can never be deleted, Free can't even be archived, and a custom plan loses Delete the moment anyone has been on it. It also quietly explains things this spec already described — Managed / Self Managed being seeded is why 7.14 shows them only to migrated users, and Legacy / Lifetime being seeded gives those existing-user states somewhere to live | FE: Plans & subscription §A, Plans |
| 7.21 Extra servers vs "free forever" | The two docs disagree, and Pair 2 says so itself (2026-10-08). Pair 1 replaced "free forever" with extra servers (0, 1, 2… for the user's own servers; limit = plan + extras; kept through a plan change; not counted in downgrade checks) and changed 7.3 to match. Pair 2 — which owns Phase 7 — has not accepted it: its 7.21 still reads "free forever", with a note "Pair 1 decision, differs, to confirm with Jayshree" | This site describes extra servers, but now says plainly that it is provisional Conflict — a callout on FE: Plans & subscription, a caveat on the plan-limit row in Servers, and the struck-through free_forever state on Subscriptions marked as a removal that may come back. The entry in sync/pending-frontend-changes.md is flagged hold. One thing holds either way: the usage display must show what the API says a user's real allowance is, never a bare plan number (D-32, D-49) | FE: Plans & subscription, Servers, Subscriptions |
| 6.4, 6.9 Managed-server limit | Changed 2026-10-26/27: the +3 per payment is gone in both docs. Pair 1 (2026-10-27) also has no managed-server limit at all; Pair 2 still keeps the limit from the admin setting — the docs differ again. Old text: Pair 1's rule, contested, then adopted by Pair 2 (2026-10-06 12:03) — settled. V7's "+3 per payment" is not on the plan's server limit — it belongs to a separate managed-server limit: it 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. Plan-billed servers follow the plan limit with no bonus | Disagreed openly for three hours, now identical. V8 requirement Pair 1 kept the bonus on the managed-server counter and recorded the split on purpose; Pair 2 took Pair 1's wording in full at 12:03, so Phase 6 is the same in both docs. This site followed Pair 1 throughout, so nothing had to change — and D-32's frontend answer never moved. Frontend consequence: still nothing to show. Because users cannot create managed servers (D-36), the managed-server limit is never reached from any screen — the top-up success message stays "credit added" with no allowance claim, and the only limit a user ever meets is the plan's | FE: Billing screens §A, Servers, Open questions |
| 7.26 Add-ons in a plan | New 2026-10-06: when creating or editing a plan the admin can assign any available add-on to it (examples renamed 2026-10-06: Log Monitoring (V7 InsightHub), White label, Reseller panel (V7 self-hosted panel), plus add-ons from later phases); users on that plan get them included. Not assignable: WP Toolkit — which now explicitly contains Object Cache Pro — and Premium Hosting Care. The downgrade check (7.8) also covers add-ons in use | The picker is built from the API's add-on list, like the feature list. Two knock-on effects: the add-ons page needs an "Included with your plan" card state separate from "Buy", and the downgrade block must list an add-on in use as a reason. It also confirms the frontend's existing rule rather than breaking it — Premium Hosting Care is shown to every user precisely because it is never plan-assigned. And it draws a line the add-ons page needs: a plan can include an add-on (White label, Reseller panel, Log Monitoring → the card reads Included) or merely gate who sees it (WP Toolkit → always bought, never included). Object Cache Pro gets no card at all — it ships inside WP Toolkit | FE: Plans & subscription §A, Plans |
| 7.1a Plan names | Added 2026-10-05: the starting plan names are not final, the admin can rename any plan, and renaming only changes the name users see — users on a renamed plan keep the same plan | A plan name is data, never an identifier: nothing may key off it — no layout, no feature check, no test fixture, no i18n key — and a rename must not look like a plan change | FE: Plans & subscription §A, Plans |
| 7.6 Trial | Conflict Overruled 2026-10-09 — V8 has no trial. Bhavik removed it: a new user picks a plan immediately at /billing/plan, with "No plans are available yet. Please ask the admin to create a plan." when the admin has made none. The backend still specifies a trial of admin-set length ending in a must-buy gate, plus trial rules in 7.1, 6.9, 6.13 and 17.19 | Nothing trial-shaped is built, and a lot comes out: the days-left banner, the trial-end gate, the trial and trial_ended subscription states and the sidebar's "trial" badge. D-33 goes moot (there is no "after a trial") and D-56 is raised for the part that is genuinely unresolved — 7.1 and 17.19 are admin settings, so an admin could be shown a trial switch that can never affect anyone. Superseded note: the end of a trial becomes a blocking choose-plan state, not a banner — a third state next to expired and locked. New question D-33: the catalogue still has a Free plan, so may it be chosen at the gate? | FE: Plans & subscription §B, Subscriptions, Plans |
| 7.12 Members locked | Added 2026-10-05: when an owner's account locks at day −15, their team members are locked too | Members need their own locked screen: it names the owner, says to ask them to add credit, and has no billing tab and no pay button. Members must also see the day −7 warning, or the lock-out arrives with no notice | FE: Plans & subscription §B, Members, Subscriptions |
| 7.18 Feature / limit change | New 2026-10-05: turning a feature off or lowering a limit warns users by email first and applies from their next renewal | A pending-change note on the current-plan card with the date and exactly what changes; today's usage bars keep today's limit. New question D-34: nothing stops the admin lowering a limit below a user's current usage, which 7.8 would refuse if the user asked for it | FE: Plans & subscription, Plans, Open questions |
| 7.19 Archive plan | New 2026-10-05: users on an archived plan keep it until they change plan; new users can't pick it | The current plan must render even when it is absent from the catalogue, and moving off an archived plan is a one-way door that the UI has to state | FE: Plans & subscription §A, Plans |
| 7.20, 7.21 Per-user plan & extra servers | 7.21 rewritten 2026-10-08 (Pair 1): "free forever" is gone, replaced by extra servers — the admin grants 0, 1, 2… for the user's own servers, the server limit becomes plan + extras, the extras stay through a plan change and are not counted in downgrade checks; managed servers stay on their own counter (6.9); V7 free-forever users migrate to extra servers = 1. (Original 2026-10-05 wording: the admin can give one user their own plan (custom price, server / app limits, cycle, expiry days) and can mark a user free forever — both as in V7 | Together with 7.19 this kills one assumption: the current plan is never looked up in the catalogue, it is drawn from its own data. Free forever shows no renewal date, no renew price and no expiry banners, and does not reuse the lifetime badge | FE: Plans & subscription §A, Plans, Subscriptions |
| 7.22 Unlock account | New 2026-10-05: a locked account unlocks automatically once the user adds credit and pays the plan. Servers removed at day −15 stay removed | The locked screen stops being a dead end: two steps (add credit → pay), no support ticket. It must be honest that removed servers don't come back by themselves — they are still at the provider and have to be connected again | FE: Plans & subscription §B, Subscriptions |
| 7.25 Expiry date & status | New 2026-10-05: a plan stores a real expiry date (not V7's day counter), days left are worked out from it, the status is active / expired / locked, and Central checks the date on every action so a missed nightly job can't keep an expired plan alive | Closes the old "V8 should expose an explicit status" gap on Subscriptions: screens read the status field instead of inferring a state from a day count. Always show the exact date, with "N days left" as a label on top of it, and never count days in the browser — a plan can expire mid-session and the next action will be refused | FE: Plans & subscription §B, Subscriptions, Plans, V7 migration |
| 7.10 Auto-renew retry | Changed 2026-10-05: renewal is attempted on the expiry day and then every day until day −15, so the plan renews as soon as credit is added (as in V7) | Changes the copy on every expired screen: adding credit is enough and there is no Renew button to press afterwards. The banners must say that, or people will add credit and wait | FE: Plans & subscription §B, Subscriptions, Servers |
| 7.10–7.12 Expiry timing is admin-set | Added 2026-10-05: the admin sets the reminder start (default 7 days before), the warning day (default −7), the lock day (default −15) and the reminder weekdays (default Monday + Thursday). Auto-renew retries until the lock day, not a fixed day 15 | Four admin settings on one page — and a hard rule for every user screen: none of those numbers may appear in a screen or a translation string, because an admin can change them. Every expiry message carries a date from the API, so the strings need a date placeholder rather than "15 days". The in-app banner also must not follow the weekday schedule: it shows whenever the plan is in that state | FE: Plans & subscription §A, Subscriptions |
| 7.12 While expired | Added 2026-10-05: between day 0 and day −15 every server action is blocked with "Plan has expired. Please renew it", but the user can still view their data, delete a server, and add credit / renew | A real UI state instead of a V7 guess, and an unusual one: pages stay readable, controls are disabled with that single message, and exactly two actions survive — Delete server and Add credit. So don't grey out or blank whole pages | FE: Plans & subscription §B, Servers, Subscriptions |
| 7.2 API rate limit | Added 2026-10-05: the API rate limit per minute is now a row in the plan feature list, with V7's numbers (Free 60 … Business 180) as starting values | Nothing new to build — it arrives as one more generic feature row, which is exactly what the generic rendering was for. The frontend does not enforce it; it reports the API's 429 | FE: Plans & subscription §A, Plans |
| 7.7 Upgrade preview | Added 2026-10-05: before paying, the user must see a preview — credit coming back, amount to pay, new end date | Settles what the confirm-and-pay dialog contains. The end date is part of the backend's quote and is never worked out in the browser | FE: Plans & subscription §B, Plans |
| 7.23 Redeem codes | New 2026-10-05: the admin creates batches of codes giving a plan or credit (AppSumo-style): quantity, expiry, on / off, download the list, see who used each code. Users redeem from their account; each code works once | New user dialog: paste → say what the code gives before confirming (a plan and credit end very differently), then land on the plan page or the wallet. Five separate refusal messages, never one "invalid code". Credit from a code is not a payment — no gateway, no tax and no receipt. Admin side: batches are the record, with per-code used / unused and by whom, and off is a status, not a delete | FE: Plans & subscription, FE: Billing screens §A |
| 7.24 Admin: plan overview | New 2026-10-05: users per plan, upcoming renewals, and accounts close to being locked | Three lists on one page, each row opening that user. "Close to being locked" is the day −7 → −15 window from 7.12, so it needs the date and days left per account, not a count | FE: Plans & subscription §A |
| Phase 7 lifetime installments | Parked 2026-10-05: lifetime owners still paying in installments (V7: 1 or 3 payments) keep their plan; how installments work in V8 is decided later | The lifetime state needs a "paid 1 of 3" line so a part-paid plan isn't shown as settled — but no installment flow is built while the decision is parked | FE: Plans & subscription, V7 migration |
| Q9 | Answered 2026-10-03: accepted — Git uses an access token / app password, Google Drive a service account, instead of V7's one-click login | No OAuth button on any integration screen; every connect form is a token form | FE: Integrations, Open questions |
| Q10 | Parked: how V7 Git / storage connections move is decided later, with the migration phase | Empty states must explain that a migrated user needs to reconnect | Open questions |
| Q11 | Dropbox skipped for now — not supported in Phase 5 | Not in the storage picker; V7 Dropbox users need a message and an alternative | FE: Integrations, Open questions |
| Q12 Hostinger | Answered 2026-10-03: not a provider. V7 only detects a Hostinger IP when adding an existing server, then removes its pre-installed Apache/MySQL. Servers-phase matter | Nothing in the provider picker. Noted on the Servers page as an existing-server case | Providers, Servers |
| Q13, Q14 | Open OSS registration after an automatic install; rotating the Central token that sits in the start-up script | Moved to the Servers phase with the create-server flow. Q13 is a security hole, not a screen — the progress screen must not reveal the panel URL before Central claims it | Open questions, Servers |
| D-27 (frontend decision) | Bhavik: integrations are account level (frontend doc 3.I1–3.I4). Backend Phase 5: cloud providers per organization | Conflict — the frontend keeps account level and flags it; only the record's owner differs, not the screens | FE: Integrations, Providers, Open questions |
| Q1–Q3 | Server fields, how the key reaches Central, offline display | Server wizard + offline states wait on these | Open questions |
| PHPStan — skipped 2026-10-03, reversed 2026-10-08: new step 1.11 installs Pint + PHPStan (Larastan) and makes Pint + PHPStan + Pest a per-task gate | Backend only. Frontend keeps ESLint + Prettier — but the backend's hard per-task gate is a fair precedent for ours | — | |
Answered 2026-10-08 — new Phase 1 step 1.10, the oldest question on this site closed. 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, falling back to English | Answered by a different route than this spec proposed, and the difference is an obligation. We asked for type + params so the frontend could translate; the backend translates server-side instead. Simpler to consume — but the BFF must set Accept-Language itself on every call, because a server-side fetch carries no browser headers. Two gaps left: the backend's language list is "decided later" while we spec eight, and there is still no profile language field | Internationalization, Open questions | |
| Phase 8 Servers: create & connect (Pair 1) | Requirements complete 2026-10-06 V8 requirement: six ways to add a server — own cloud account (8.1) · managed (8.2) · existing server by root password (8.3) · existing server by install command (8.4) · connect an existing OSS panel (8.5) · the free "ServerAvatar Lite" (8.6). Plus stack & install options (LEMP, LAMP, OpenLiteSpeed, MERN — no Docker, no database at creation, and from 2026-10-06 an optional "force cleanup" on every way that installs), pre-create checks (user and owner email verified, plan active, server limit, provider enabled, IP not already used), live install progress with Retry / Delete, token handling and what Central stores | Full screen spec written. Answers Q1 (8.11) and Q2 (8.10) — the two oldest questions on this site, both now removed from the backend's own list. Three details worth carrying: the stored OSS copy is one-time, taken at connect, so IP / OS / CPU / RAM / disk / app count can go stale (which is exactly why Q3 still matters); the installer saves the token automatically in five of six ways, so only "connect a panel" ever shows a token field; 8.7 confirms Bhavik's "no database-engine field" and adds a real control — force cleanup is a tick-box the user chooses, not something silent. Raises D-41 (ServerAvatar Lite has no screen anywhere) and the D-36 managed-server conflict is now stated in two phases | FE: Add a server, Servers, FE: Integrations §B, Phases |
| 8.1, 8.7 Ubuntu versions · 8 "not in this phase" Unclaimed server | Both decided 2026-10-07. The version choice is 22.04, 24.04 or 26.04 — 20.04 is out of V8 and the installer refuses a server on any other version. MongoDB is not available on 26.04 (an OSS limit). And the unclaimed server case, which had been "waiting for a decision from higher authority", is not in V8 at all | Two questions off the list V8 requirement. The version list is now a known set of three, which also confirms the V7 migration blocker this site has carried since 2026-10-03: a V7 server on 20.04 cannot come across. The MongoDB limit creates a real wizard rule — MERN and 26.04 cannot be chosen together, so the stack and version fields must constrain each other before the review step, with the reason named; and for an own server, the version check belongs in the pre-check, not as a mid-install error. The unclaimed-server removal is the cleaner kind of answer: nothing to design, and no screen should offer to claim a server | FE: Add a server, Servers, FE: Integrations |
| 8.6 ServerAvatar Lite | New to this spec 2026-10-06, then corrected the same day: V7's free managed server is kept — an install script registers a server without a ServerAvatar account, attached to ServerAvatar's own accounts and plan, giving a limited panel login (100 apps, 100 databases; backups, Git, Fail2ban, staging, clone, workers, cloud storage and disk cleaner off). The correction: OSS is NOT installed on this type — the phase goal says so, and the automatic-token rule (8.10) was narrowed to 8.1–8.4 to match. Re-installing on the same IP replaces the old one | Even further outside Central than it first looked. No Central account and no OSS panel — and every server screen in this spec is driven by the OSS API, so Central could not manage one even if it wanted to. Whatever provides that "limited panel login" is not named. Still D-41 for Bhavik: whether Central's frontend owns a landing path or that panel's login at all. Nothing invented | FE: Add a server §A, Open questions |
| 8.9, 8.10, 8.11 Install, token, stored data | Live install steps with a reason on failure and Retry / Delete; the installer writes the token into both OSS and Central for 8.1–8.4 and 8.6 (only 8.5 is pasted), encrypted, never shown or logged; Central stores the link record 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 starting as the OSS hostname | Confirms the progress screen and cached-list-fields proposals this site already made (D-11). The sharp edge is the word one-time: a screen showing those facts must either label them "at connect" or read live, because nothing promises they stay current — the refresh story is parked | FE: Add a server §B, Servers |
| Phase 9 Server panel features (Pair 1) | Complete 2026-10-06, revised 2026-10-07 after a check against V7 — the biggest gap on this site is closed. 9.1–9.30: the server list from Central's own data (search by name / IP / provider / OS / stack, filter managed or not, sort, 12 per page), shared with me, deleted servers & restore with no time limit (managed servers excluded), power on / off and resize for managed servers only, delete with an optional provider deletion (always for managed), disconnect which leaves the server running and makes Central ask OSS to revoke its own token, tags marked "decision pending", then every menu screen 9.9–9.30 and the rules 9.31–9.33 (plan limits, view / manage permissions, activity log read from OSS). The 2026-10-07 revision made database engines add-only (OSS has no remove) and added root SSH access per user (9.11), a web-server config test before restart (9.15), backups of deleted servers stay listed and downloadable (9.21), server alert limits (9.28), change the server's IP in Central (9.29) and PHP-FPM config (9.30) | New page: FE: Server screens. Three long-standing items answered: Central can now revoke its own key on disconnect — the warning that stood on Servers from the beginning; deleted servers + restore has rules, so it stopped being a parked V7-only feature; and resize is kept for migrated managed servers. New decision D-45 — Docker (9.18), Panel update (9.24) and Service monitoring (9.25) have no place in the fixed server menu. D-37 got sharper, not weaker: Phase 9 lists the menu screen by screen and there is no Notifications screen, while 11.7 puts channels and alert limits at Server → Notifications | FE: Server screens, Servers, Server list & details |
| 9.28 Server alerts | New 2026-10-07: the user sets the limits that trigger an alert — CPU, memory, disk, load — and the alert goes out through Phase 11. Needs OSS API support | This answers half of D-37. Phase 11 (11.13) said alert limits are set per server by the user, with V7's defaults, but never said where that screen lived; 9.28 puts it in the server panel, so this spec stops guessing at Server → Settings. The half still open is the channels screen of 11.7 — Phase 9's menu has no Notifications item at all | FE: Server screens §C, FE: Notifications & mail, Open questions |
| 9.10, 9.21 Two rules that change a screen's shape | 9.10 corrected 2026-10-07: database engines are add only — no remove, because OSS has no remove. 9.21 added: backups of deleted servers stay listed and downloadable, as V7 | Add-only is not a missing button, it is a permanent act — so installing an engine is a CONFIRM that says so, and the list shows no delete action rather than a disabled one. Deleted-server backups need a home, because they outlive the server they belong to: either the deleted-servers page (9.6) lists them or there is one account-level list. The backend does not say which, so this spec does not choose — but it must not hide them | FE: Server screens §C |
| Phase 10 Application panel features | Requirements complete 2026-10-06. Written 2026-10-05, restructured the same day to follow the OSS app panel tab by tab, then marked complete with the words "Central simply uses the OSS API". Now 10.1–10.20 (create app by category · overview with attention checks, protection summary, first-run credentials shown once, magic login, root lock · app actions incl. delete with files and databases · domains & SSL with DNS check and dry run · files with trash + restore and size per folder · logs · PHP + isolation · environment with history / compare / restore · deployment · databases + one-click phpMyAdmin · backups (same server only) · staging · clone · workers (Node apps are services) · security = password protection, firewall, bot blocker, Fail2ban as four separate tabs · container & compose · settings) plus three Central rules: 10.21 plan limits (app features join the plan feature list; Free starts without workers, app security, web firewall, separate database server, multiple domains), 10.22 view / manage permissions per feature, 10.23 app activity log read from OSS. Central stores no app data. On 2026-10-06 the list of 10 V7 features OSS does not have was removed from the backend doc and parked | Full screen spec rewritten to the new numbering. Three things worth carrying forward: the attention checks in 10.2 are a per-app version of the all-servers "Needs attention" screen and should look alike rather than be invented twice; first-run credentials shown once is the other half of the no-secrets-in-email rule, making the panel the only place they appear; and 10.23 vs 11.11 is a clean distinction — this screen reads the OSS activity log while notifications deliberately do not, so the app history is complete but the notification feed only covers what Central did. 10.21's named plan and its exclusions are the admin's starting data, not frontend constants, so tabs are hidden from the plan feature list, never from a hard-coded list. Raises D-40 (four tabs have no place in the fixed app menu) and keeps D-39 (blueprints). Our page is now the only written record of the ten parked features — the same situation as Q13 / Q14, so they are kept deliberately | FE: Application screens, Server details, Blueprints, Open questions |
| 11.20 Who gets a notification | Reversed twice on 2026-10-05, final wording 12:04: server, app and organization events go to the organization owner only (as V7); account events (security, billing, plan) go to the account user. The earlier "owner and members with access" is gone | This site had recorded the intermediate version as a change from V7 — corrected, not quietly edited. So the bell is effectively an owner feature for servers, apps and the organization: a member can open the notifications page and legitimately see nothing, and the per-server channel screen is an owner tool. Account events still reach each user. Raises D-38: a member with real access to a server is not told when its backup or SSL renewal fails, so the person who can fix it isn't notified. V7 did the same, so it is "no change" rather than a regression | FE: Notifications & mail, Members, Open questions |
| Phase 11 Notification & Mail | Requirements complete 2026-10-05 V8 requirement: admin SMTP + test email, background sending, shared layout with translation keys, sent log; one event list (key, group, default channels, required) that every phase adds to, one sender, user picks events per channel and per server, account / billing / plan events can go to channels, failing channels marked "not working", unsubscribe link; server & app events by polling each server's OSS panel; follow-up emails, unverified reminder, announcements, Mautic | Full screen spec written. Answers D-17 (where alerts come from) and moves Q8 forward (emails use translation keys). The settings screen must be a matrix built from the event catalogue, like the plan feature list — otherwise every later phase edits it | FE: Notifications & mail, Notifications, FE: Account screens, Internationalization |
| Phase 12 White label add-on | New 2026-10-06, and marked complete the same day: two halves. A — Control Panel (12.1–12.6), for every user, no add-on: one customer login per server (username min 8, password min 8 hashed, email), app and database limits 0–2000, a permission tick-list per app feature, one-click login, and a customer panel showing only that server with the Phase 10 screens, a 1-day session, timezone / change password / logout. B — White label (12.7–12.11): on for the whole account and lifetime (12.7 / 12.11, changed 2026-10-06 — a plan grants it once after payment and a plan change never removes it; only an admin can), branding (app name + folder name set once, "serveravatar" banned, title, tag line, brand colour → palette, logo, icon, favicon, header / footer, GA ID), own domain by CNAME + Check CNAME + automatic SSL, panel settings (SMTP + test, Git apps, cloud storage apps, DNS via Route53 / DNSimple, default server pages), and if an admin switches it off, branding and the domain stop while the Control Panel keeps working on the default manage domain. The login domain rule is V7's and must not change | The first phase that asks for a second product, not another screen. Everything specced so far is one app, one login, one domain; this is a signed-in surface for people with no Central account, served on the default manage domain and every owner's custom domain, branded per host — raised as D-42 instead of assumed. It also makes one earlier instruction binding: the Phase 10 app screens must be permission-driven and server-agnostic from the start, because 12.6 reuses them with a smaller permission set. Two more decisions raised: D-43 (the fixed server menu has no Control Panel item) and D-44 (one brand colour → a whole palette, against our fixed token set) | FE: Control Panel & White label |
| Phase 13 Log Monitoring add-on | New 2026-10-07, rewritten three times and extended to 13.1–13.12 the same morning; ✅ complete, with its two OSS dependencies owned by the OSS team. Final numbering 13.1–13.9: collecting logs is the new 13.5, so reports are 13.6, update 13.7, remove 13.8 and the activity log 13.9. Numbering moved — update is 13.6, remove 13.7, activity log 13.8. V7's InsightHub, rebuilt as reports inside Central — the separate InsightHub app, its domain and the domain-change flow are dropped. 13.1: included in a plan (7.26) or bought, enabled automatically when an eligible plan is taken and paid, and tied to the plan — a downgrade switches it off and removes it from every server, as V7 does. 13.2: the toolkit checks a licence service on every request, recognising a server by IP. 13.3: the user installs it per server — Central first asks OSS whether the toolkit is already there, then installs the program, a settings file and a new database plus two jobs, fetch (new log lines about every 15 minutes) and prune (deletes data older than the retention days, default 7), with live progress; OSS has no way to receive it today, so this step cannot be built. 13.4: after install the server's apps are monitored automatically, new apps included, with an on / off per app. 13.4: each app is registered with its name, system user, domain, web server and SSL, and domain or SSL changes update the registration. 13.5: reports in the Application panel — 49 reports in six groups, some taking a limit, a field or a status code; zeros before the first fetch are not an error — Central shows "collecting data". 13.6: update, then a one-off bot-detection re-check. 13.7: remove — unregister every app, stop both jobs, delete the program and its database with every collected statistic; reinstalling starts fresh, and a plan downgrade does the same on every server. 13.8: activity log | New page: FE: Log Monitoring. The sharpest point is a contrast: two add-ons now have phases and they behave in opposite ways — White label is lifetime with no off switch (12.11), Log Monitoring is removed from every server on a downgrade (13.1). So one card design cannot serve both, and the downgrade check (7.8) must name Log Monitoring while staying silent about White label — fixed on FE: Plans & subscription, whose stale example now reads "3 servers would stop being monitored". D-46 raised: six report groups land in the app panel and the install action is server-level, and both menus are fixed with no item for either — the largest placement question yet, and the reports have no OSS screen to copy because the OSS panel has none. Two gaps named rather than guessed: the licence recognises a server by IP while 9.29 lets the IP change, and 13.6 points at "the open point on keeping data" which is not published, so the remove confirm promises nothing. Log Monitoring also left the out-of-scope lists on Product overview, FE: Application screens and FE: Notifications & mail — where dropping the InsightHub app also retires V7's "monitoring domain change" message | FE: Log Monitoring |
| Phase 14 Premium Hosting Care add-on | New 2026-10-07, completed the same hour. V7's managed-support pack: a private Slack support channel and proactive uptime monitoring. 14.1: bought per account, never part of a plan (which explains 7.26's "not assignable"), cycles 1, 6 or 12 months, paid from the credit balance with tax, charge saved, purchase email. 14.2: price per cycle, renew price and the discount rules are admin-managed (V7 hardcoded them). 14.3: its own expiry date with reminders and auto-renew from credit — the same engine as plans; too little credit and it expires. 14.4: Cancel stops auto-renew and the pack runs to its expiry date. 14.5: the user gives an email and the support team invites them to Slack by hand. 14.6: on / off per app, in the app's Settings tab — a Central-only option, hidden or locked without the add-on; Central checks each enabled app's public address from outside every 7 minutes (status code, response time, up / down / SSL error); the switch and the results are saved in Central, not OSS; phpMyAdmin apps skipped and an app deleted in OSS is turned off. 14.7: alerts only on a change of status, and an SSL error that still answers 200 is not alerted. 14.8: when it ends, monitoring stops everywhere and Slack is support's business. 14.9 admin list and per-user edits, 14.10 activity log. Not in V8: V7's "X of Y sold" counter | New page: FE: Premium Hosting Care. The clearest thing this phase adds is a contrast worth designing around: three add-ons now have phases and all three end differently — White label never ends, Log Monitoring is taken away by a downgrade, and this one has its own expiry with auto-renew — so the add-ons page needs three card shapes, not one. Two more things stand out. 14.6 is the only app screen in the whole spec that does not read through the OSS panel: Central calls the app's public address from outside, 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. And it has a real per-app switch, the exact opposite of Log Monitoring, which deliberately has none (13.4). D-47 raised for where that switch and its status live in the fixed app menu. Three smaller gaps named rather than guessed: whether there is any uptime history or only the current status, who the user hears from about the Slack channel after the pack ends, and whether the discount is shown as a discount | FE: Premium Hosting Care |
| Phase 15 Reseller panel add-on | New 2026-10-07, marked 🟡 with the install flow (15.3, 15.6) explicitly not final — and from 14:37 those open points have a named owner: Jayshree, when the phase starts. V7's "Self-hosted" panel: a lifetime licence (included in a plan or bought, never removed) and a licence key; a Reseller panel page showing key, activated domain, install status and version; Install = the user picks a server and a domain and Central installs the panel through the OSS API as an ordinary Git app — no V7 agent — with settings, deploy script, worker, cron and SSL, and live progress; Activate happens inside the reseller's own panel (domain + key), which locks the licence to one domain; Change domain goes request → email link → confirm; Update triggers a deploy; Delete removes it through OSS and frees the licence's domain; and the installed panel calls Central with its licence to list organizations, add servers and create Control Panel users (Phase 12). Not in V8: V7's pre-booking promo | New page: FE: Reseller panel. This completes the set: all four add-ons named in 7.26 now have phases, and two of them — White label and this one — are lifetime. Three things are worth more than their size. It is the third surface that talks to Central (after Central itself and the Control Panel) and the only one Central installs onto a customer's own server, which also means the panel shows up in that server's app list as a real app. Activation is not our screen — it happens inside the reseller's panel — so Central's page owns the result and must explain the one-domain rule before they choose. And the backend's own "not final" marking matters to the frontend: a Git deploy and a Docker pull fail and progress differently, so the install screen should not be built around either yet. D-48 raised for where the page and the Install action live — the sixth placement question of this family | FE: Reseller panel |
| Phase 16 WP Toolkit add-on | New 2026-10-08, filled out to 16.1–16.15 and marked ✅ complete the same morning; three points are left to decide at implementation. It runs exactly like Log Monitoring: a wp-toolkit program on the server, the OSS backend runs its commands, Central uses a Central-only WP Toolkit API, and the licence is checked per command by server IP (16.9 = 13.2). 16.1: bought per account, recurring monthly / yearly, never in a plan, and one purchase covers every WordPress app on every server including later ones. 16.2: admin-managed price; V7's fixed prices and "first 100 buyers" counter dropped. 16.3: same expiry engine as Premium Hosting Care — and when it ends the screens lock while everything done to the sites stays. 16.4: Central installs and enables it automatically — there is no install screen. 16.5: the biggest group of app controls in the product (core, plugins and themes, tools, debug, site settings, security, maintenance mode). 16.6: background actions with progress. 16.7: blueprints are saved plugin and theme sets kept in Central, applied at app creation. 16.8: Object Cache Pro per app with the user's own key, encrypted, a Redis user per site and a new change-password-without-downtime action. 16.10: a WP Toolkit app permission for members. 16.11: the admin can give or remove it. V7 buyers keep it for life, free | New page: FE: WP Toolkit, and it closes two long-open questions. D-15 — who installs and licenses WP Toolkit — is answered: Central does it automatically, there is no install screen at all, and it is a paid per-account add-on. D-39 — whether WordPress blueprints exist in V8 — is yes, and they live in Central, which matches Bhavik's 2026-10-06 decision, so the long-standing uncertainty on Blueprints and FE: Application screens is retired. But the shape is narrower than this site assumed — plugins and themes at creation, not V7's cleanup options, locale and permalinks and not a run against an existing site — so the Blueprints page says so and is marked for rewriting. A fifth add-on ending: locked, nothing undone — the kindest of the five, and worth saying in those words on screen. D-51 raised for where this group lives in the fixed app menu, with the wrinkle that maintenance mode may move out of the add-on. One risk the backend names itself: its chosen option leaves V7 Object Cache Pro sites on the old shared-Redis setup and warns they may silently stop caching — so if that stands, the screen must show a site's real state, not just "on" | FE: WP Toolkit |
| Phase 17 Admin panel (Pair 1) | New 2026-10-08 — the first admin phase the backend has published, 17.1–17.23, same flow as V7. Access: an admin is an ordinary account marked administrator (no second login), one role per admin from a seeded permission list arranged menu → sub-menu, the sidebar is built from the role, and every admin route checks its permission — including site settings, roles and DNS, which V7 left open. Then: dashboard (totals, transactions, charts, breakdowns by web server / provider / OS); users (list, three statuses — banned, locked, active — create, stats, deleted users, referred users); one user's page (servers, organizations, login and activity history, 2FA on / off and backup codes, IP whitelist); billing per user (transactions added and edited by hand, charges, invoices, codes used); plan per user (custom plan, add-ons, managed-server limit, extra servers); log in as user; organizations (incl. deleted servers & restore and backups); servers (usage, services with the config test, apps, databases, system users, reboot through the provider) and move a server to another account; plans, promo and redeem codes; settings (site, providers and prices, general incl. a display-message banner and the referral program, integration keys with a test mail, DNS, and the settings other phases own); and an error monitor with secrets stripped | New page: FE: Admin panel — every admin screen on this site was a V7 guess until today. Three answers worth having: server transfer is settled — 17.13 makes it an admin action with no user request flow, which is exactly Bhavik's 2026-10-07 rule, so the two now agree; a new app's temporary domain is <app>.<server-ip>.nip.io with HTTPS from OSS (10.1), and Central creates no new temporary domains at all — its DNS settings exist only for White label and old V7 domains (17.21), which closes a question open since Phase 10 and sharpens 12.10; and the free managed server is gated by a partner list in the admin settings (17.22), one more piece of D-41. D-50 raised: the phase says what each screen contains but nothing about the shell — and since the sidebar is role-built and every route is permission-checked, that is a real decision, not a detail. One conflict: 17.11 gives the admin deleted servers & restore, which Bhavik ruled out of V8 for the user side — admin-only may be a different call, so it is flagged, not written. Two smaller gaps: where an admin reads the combined-role migration report, and who notices if an old V7 temporary domain lapses | FE: Admin panel |
| Phase 18 Referral & Affiliate | New 2026-10-08 — requirements complete, and it splits the pair that this site has always listed together. Referral is Central's (18.5–18.11): every user gets a link (?r=CODE) with clicks counted; signing up through one adds the new user's credit straight away, provided the referrer is active; a daily check then pays the referrer once — plus an email — as soon as the referral has a plan and has paid at least the minimum amount; a referral page shows link, clicks, signups and approved referrals; the admin sets on / off, both credit amounts and the minimum payment in 17.19, with a top-referrers list; one notification ("referral credit received") and two activity-log entries. Affiliate is Tolt's (18.1–18.4): the Tolt code is saved at sign-up from the link — email and Google / GitHub routes — and sent with the user's Stripe payments (ordinary and auto-recharge), only for users who signed up under a year ago and never for server-credit payments; Tolt computes the commission; the admin stores a Program ID + token, encrypted. 18.3 is absolute: Central has no affiliate dashboard, no commission slabs, no payouts. Not in V8: V7's whole built-in affiliate programme — apply form, approval, slabs, monthly commission job, PayPal payouts, banners, custom links. 18.12 settled minutes later: a user holding both a Tolt code and a referral code earns both — separate rewards (the affiliate's commission in Tolt, the referral credits as normal), which is already V7's behaviour | New page: FE: Referral & Affiliate, and the headline is what Central does not build. This corrects a row this page's own sibling published four hours earlier: after Jayshree's morning note, FE: Admin panel said the admin affiliate screens were dropped "but the user-side affiliate is kept" and that the user keeps an affiliate area. 18.3 says otherwise — nobody gets an affiliate screen, user or admin; "kept" means affiliates keep earning, in Tolt. The row is rewritten. So A9 Admin: affiliate program should be marked not in V8 rather than left pending — there is nothing to wait for. The useful distinction is the reward: referral pays credit, which Central can grant and spend, so it needs a few screens; affiliate pays money, which needs tax and payouts, so it left the product. That also answers any future "withdraw my referral credit" request — referral credit is not cash. One number needs a sentence, not just a count: approved referrals only rises once a referral takes a paid plan, so a user with ten signups and no credit must be told why. Three answers came free: D-23 is down to the AI assistant alone; the V7 email map's last deferral but one closed ("referral credit received" → 18.10, affiliate request / approved dropped); and the sign-up form's pre-filled code field is confirmed for both code types. D-54 was raised and answered inside the hour: 18.12 first read "only one counts — which one to confirm", and the confirmation reversed it to both. The lasting consequence is the same either way — the frontend doc's "affiliate code wins" is wrong, because it described V7's built-in affiliate competing with a referral and that system is gone. Also updated: Product overview, FE: Billing screens, FE: Account screens, FE: Auth screens, V7 migration, Open questions | FE: Referral & Affiliate, FE: Admin panel, FE: Billing screens, Billing |
| 12.10 Owner's own SMTP | Closes the last deferred row on the notifications page, and the DNS block answers where temporary app domains come from — a gap this spec had left open on the app-domain screens | FE: Notifications & mail, FE: Control Panel & White label | |
| 12.7, 12.11 + 7.26 White label is lifetime | Changed 2026-10-06, about forty minutes after the phase was first published. When a user takes and pays a plan that carries White label, it is added to their account as purchased (lifetime) and shows as purchased; it can also be bought on its own. Once on the account it stays for life, through any later plan change — and in the 11:37 wording there is no on / off switch at all, as in V7 (an intermediate version said only an admin could). 7.26 names it as the exception to the downgrade check. V7 owners who have it (bought, or from the Business plan) keep it | It reverses what this site published at 10:45, which said a plan change or expiry switched the add-on off. Three consequences, all stated on the pages rather than quietly edited: the add-ons card reads Purchased, not Included, and carries no expiry; a downgrade must not warn about losing White label and the plans screens must not list it as a blocker (7.8); and there is no switched-off state to design at all — the earlier "paused, ready to come back" wording was wrong, and so was the "only an admin can" version that briefly replaced it. The backend also dropped its sentence that branding and settings are kept for later, so this site no longer promises that either | FE: Control Panel & White label §B, FE: Plans & subscription |
| 12.6a–12.6c, 12.10a, 12.10b, 12.12 Phase 12 fills in the V7 detail | Added 2026-10-06: inside the Control Panel the customer connects their own Git and cloud storage using the owner's app keys (12.6a); the customer sees only the app types the owner allows (12.6b); control panel user and permission / limit changes are written to the owner's activity log (12.6c); the owner can turn the DNS provider on / off and view its records (12.10a) and preview a default page before saving (12.10b); and a private link creates a Control Panel user for partner emails — list kept in settings — returning the server's install commands (12.12). An "admin side" line about turning the add-on off appeared with these items and was removed again within the hour, when 12.11 settled on there being no off switch | 12.6a explains why 12.10 asks for Git and storage client IDs and secrets — the OAuth app is the owner's, the account is the customer's — so the Control Panel needs its own small integrations screen that never shows the owner's keys. 12.6b widens 12.3: the permission list picks app types, not only features. 12.6c adds event types to the existing Audit log. 12.10b settles how owner-supplied markup is handled — sandboxed preview before Save. 12.12 is probably the other half of D-41 Assumption: Phase 8's free server gives a "limited panel login" with no Central account, Pair 1's Phase 9 still lists it as "hosting users — part of 8.6, still open", and 12.12 describes exactly such a login. The two line up, but neither doc says they are the same, so they are not merged here | FE: Control Panel & White label |
| 12.4a, 12.10c + Dropbox The last three Phase 12 items | Added 2026-10-06 (phase now marked complete): the owner can find a server's Control Panel user by the server IP (12.4a); the Settings screen shows the exact redirect / callback URLs, built from the owner's own domain, to paste when creating their GitHub, GitLab, Bitbucket and cloud-storage apps (12.10c); and Dropbox is skipped in the Control Panel for now, the same as Phase 5 (12.6a) | 12.10c is the step that makes 12.6a usable, and the easy mistake is obvious once written down: the callback URL comes from the owner's custom domain (12.9), so it changes when that domain is connected and must be read from the API rather than assembled in the frontend — with the screen saying it will change while the owner is still on the default domain. 12.4a says something about how owners work: they know the IP, not the Central record, so the lookup belongs in the search they already use (9.1 searches by IP) instead of a screen of its own. Dropbox needs no new thinking — FE: Integrations already handles it as Q11 for Phase 5, so the Control Panel picker leaves it out and reuses the same message | FE: Control Panel & White label, FE: Integrations |
| Phases 6–13 Both docs | Copied in both directions over two days, and now covering everything. 2026-10-06 09:00: Pair 1 copied 7, 10 and 11 from Pair 2; 11:58: Pair 2 copied 8 and 9 back from Pair 1; 12:03: Pair 2 adopted Pair 1's Phase 6 wording; 2026-10-07 05:35: Pair 1 copied Phase 12 (identical) and Phase 13 (one revision behind — it still shows the old 13.7 and the 🟡 status) (plans incl. system/custom plans and 7.26 add-ons, adding a server, the server panel, application panel features, notification & mail) | A clean cross-check, now in both directions. Everything this site specced for Phases 7, 10 and 11 was read from Pair 2 alone, and Phases 8 and 9 from Pair 1 alone; a second doc now states the same rules, so none of it rests on a single source. No frontend change was needed either time — that is the result worth recording | FE: Plans & subscription, FE: Add a server, FE: Server screens, FE: Application screens, FE: Notifications & mail |
| 11.5, 11.6 Event list & one sender | One catalogue of events with required ones that can't be turned off (security, billing); each phase adds its own; one place decides email / in-app / channel | The notification settings screen is generic — groups down, channels across, built from the API. A required event is a locked row with a reason, not an unexplained disabled checkbox. New events must appear without a frontend release | FE: Notifications & mail §B |
| 11.7, 11.8, 11.9 User choices | Rewritten 2026-10-05 10:47. Channels are attached per server (Server → Notifications, as V7) and each attached channel gets six event-group ticks — Alerts · Backups · Apps & deploys · SSL & domains · Databases · Server changes — all on by default. The four account groups (Security, Billing, Plan, Organization) are not tied to a server and are chosen once in Account → Notification settings; account, billing and plan events can go to channels at all, which is new in V8. A channel that keeps failing is marked "not working" | This replaced the design this site had proposed — one global events × channels matrix with per-server overrides — with two simpler screens, and in doing so answered the "per-server settings at scale" worry it had raised. Because every server group is on by default, the per-server screen's job is turning things off, so it must read "you get everything; untick what you don't want" and never show an empty state. The account screen is separate and smaller: four groups, three of them locked. A "not working" channel must show that state in both places it appears. New question D-37: the backend puts the per-server screen at "Server → Notifications" but the frontend's server menu order is fixed and has no Notifications item | FE: Notifications & mail §C, FE: Account screens, Notifications |
| Event groups (final) | Published 2026-10-05: ten fixed groups with everything each one covers — server level: Alerts, Backups, Apps & deploys, SSL & domains, Databases, Server changes; account level: Security, Billing, Plan, Organization (the first three required) | The group names are fixed and few, so they can be translated and laid out properly instead of rendered from an open-ended list — while the events inside them still come from the event list (11.5), so later phases add events with no frontend change. Note the asymmetry: only account groups are required, so a user can switch off their own server alerts — the per-server screen should say what unticking Alerts costs. It also doubles as a checklist of which screens raise notifications, which retires the hand-written type list this site used to carry | FE: Notifications & mail §C, Notifications |
| 11.11–11.14, 11.20 Server & app events | Reworked 2026-10-05 10:19. 11.11: actions done through Central are sent right after OSS answers (success or failed); long actions (deploy, restore, SSL request, add-on runs) are followed by a background job and sent when finished; actions done directly in the OSS panel are NOT sent; no activity-log reading and no OSS changes. 11.12: scheduled checks of existing OSS APIs — backups (15–30 min), SSL (daily), auto-deploy (every few minutes), metrics (5 min), services, health — with how often set by the admin; replaces V7's own monitors. 11.13: every 5 min Central reads live metrics and compares them with limits the user sets per server (defaults CPU 100%, memory 80%, disk 90%, load 5 min = cores + 0.3, load 15 min = cores + 0.1); the alert carries the top processes; load alerts at most once a day per server. 11.14: one alert until fixed, then "back to normal". 11.20: the send pipeline — event list → who gets it (owner + members with access to that server / organization + the actor) → already-sent check → user choices (required events always by email) → skip "not working" channels → background send → sent log with retries | This corrected two things an earlier version of this page asserted: there is no OSS activity log reading, and work done directly in the OSS panel is deliberately not notified — so the feed is not a full history of a server. Also corrected: the alert limits are the user's, per server, not an admin setting, which means a per-server alert-limits form to build whose defaults depend on the server's core count. The alert includes top processes, so the notification needs room for a small table. From 11.20: the in-app list is permission-scoped (two members of one organization see different notifications, so never cache it across users), and required events go by email whatever the settings say. Freshness is now partly published but the interval is an admin setting, so no screen may state it | FE: Notifications & mail §D, Notifications, Server details |
| 11.1, 11.4, 11.12, 11.17 Admin side | SMTP settings + send test email, searchable sent log (event, user, channel, sent / failed, error), how often the scheduled checks run (11.12 — not the alert limits, which are the user's per server), announcements to all or chosen users by email and in-app | Four admin screens the frontend had none of. The sent log is where support will live, so it needs filters and the real error text. Announcements have no resource to link to, so the bell must render a plain message without a dead "view" link | FE: Notifications & mail §A, FE: Notifications & mail §E |
| 11.15 Credentials emails | Rewritten 2026-10-05: when server / database / app credentials are created the email says "your credentials are ready — view them in the panel". No passwords in emails — V7 sent them in plain text | A security improvement that lands a requirement on the frontend: the email is now only a pointer, so the panel must actually show credentials on demand (reveal / copy) and a generated password shown once at creation needs a way to retrieve or reset it later. Recorded on Security too | FE: Notifications & mail §E, Security |
| 11.19 Security emails | New 2026-10-05: password changed, new login from a new device / IP, API token created — all required, can't be turned off | They sit in the Security group, one of the three required account groups, so they show as locked with a reason rather than a dead checkbox. They match screens that already exist (3.4 password, 2.8 new-IP approval, 3.13 migrated token), so nothing new to build | FE: Notifications & mail §E, FE: Account screens |
| Phase 11 emails that stop | Added 2026-10-05: dead or unused V7 emails are not sent in V8 — old invoice-billing emails (monthly invoice, payment due, deactivate organization, inactive service), the wallet negative-credit email, self-managed server reminders, and the follow-up emails 11.15 used to describe | Confirmation rather than new work, and it closes two loops: the wallet negative-credit email matches the wallet track Pair 1 removed from Phase 6, and invoice emails disappearing matches Phase 6 saying receipt, not invoice. So no screen offers to resend an invoice email, and nothing promises a follow-up | FE: Notifications & mail, Billing |
| 11.21 Email clean-up | New 2026-10-05: no secrets in emails — 2FA backup codes shown once on screen (+ download), the email only says codes were generated; "DB root password changed" carries no password. One email per family: managed-server credit 10 → ~4 (trial and days left inside), plan reminders → one "expires soon" + one "expired", auto-recharge setting + card updated → one "Billing settings changed". Old invoice "Payment received" dropped | One real screen change: Account → Security must drop its "email backup codes" action — both this site and the frontend doc offered it, and it would now email a secret. Codes are shown once with copy and download, so the dialog must make "save these now" unmistakable. The merged families also argue for merged in-app banners — one managed-server banner with the days left, not four. An admin "email a user their backup codes" action was removed from the proposed admin screens for the same reason | FE: Notifications & mail §E, FE: Account screens, Security |
| 11.22, 11.23 Subjects & new emails | New 2026-10-05: one subject style that names the server or app ([ServerAvatar] web-01: Disk usage 92%); and seven new V8 emails — account deleted, logged out of all devices, plan changed with credit back and amount paid, price / feature change notice, redeem code applied, channel not working, admin announcement | Nothing new to build: every one of those has a screen already in this spec, so it is a check that each leaves a matching record. The subject rule confirms the in-app list should also name the server so the email and the bell read alike | FE: Notifications & mail §E |
| V7 email map (90 emails) | Published 2026-10-05: every V7 email marked kept / changed / merged / moved to a later phase / dropped. Also decided: no flood limit, no digest email, no reply-to support address | Two frontend readings. It names the areas whose screens do not exist yet — Premium Care, managed-hosting resize, support tickets, affiliate credit, Log Monitoring, Reseller panel / White label — which matches our Phases roadmap. And it confirms nothing a V7 user depends on vanishes silently: everything dropped was an unused job or the old invoice flow Phase 6 replaced. No digest means there is no "daily summary" preference to design, and with no flood limit the send-once rule (11.14) is what keeps the bell readable — load-bearing, not a nicety | FE: Notifications & mail, Phases, V7 migration |
| Phase 11 existing users | Channels and their per-server links, email preferences and in-app notifications carry over; every existing email keeps the same purpose and trigger | Both settings screens open pre-filled, and migrated per-server links arrive with all six groups ticked, so nothing changes for an existing user. Old in-app entries may carry an event key that is no longer in the catalogue, so render them from their stored text instead of failing | FE: Notifications & mail, V7 migration |
| Servers, dashboard, blueprints, global search, server audit | Still not in the backend doc (as of 2026-10-05). Organizations, members and roles are Phase 4; providers Phase 5; billing Phase 6; plans and subscriptions Phase 7 | Frontend pages show V7 / OSS / demo-based proposals, marked Missing / Open question | Core platform + Modules sections |
#Change log (frontend spec vs backend doc)
| Date (UTC) | Backend change | Frontend update |
|---|---|---|
| 2026-10-12 11:10 | Consistency fixes (Bhavik). No backend change | Flow doc U9.6 Cards: card-saving consent + I agree before the card form (API #50); Set default / Remove done at once, "Processing…" only when the provider is slow; Remove refused while a payment is in progress (409 card_in_use). Entry 57: obsolete mandate/activation waiting reasons replaced by the backend blocked reasons (#58: disabled, gateway_unavailable, missing_card, card_unavailable, payment_unresolved, not_available_india); same card fixes. Entry 57 still pending; no India mandate flow |
| 2026-10-12 10:55 | Bhavik approved pending entry 60 (B6.5 follow-up). No backend change | Flow doc U9 Billing: Auto recharge (U9.5) hidden for India with the note "Auto-recharge is not available for India." (turning off always works, India adds credit by hand, no mandate step); Cards (U9.6) add-card opens the card form straight away, wait state only when the provider is slow; screen states updated. Entry 57 India mandate steps replaced by the B6.5 India rule (57 itself still pending). Checked against Pair 2 API #49–#61. Real payments still off. Entry 60 complete |
| 2026-10-16 07:20 | Bhavik decided D-64 (no backend change). | D-64 marked Decided in Open questions; FE: Admin → Site settings callout rewritten: header/footer code never rendered; allow-listed snippets (GA via analytics ID first, chat widgets later as provider + ID); no third-party script on sign-in pages or admin; strict CSP; backend ask to Pair 1 (structured fields / stop returning in API97, audit log, 2FA). Verified cloud server (API71–75, DigitalOcean + Vultr) and Site settings (API93–97) specs against the current API references: match. Live deploy blocked: doc server 23.172.120.79 unreachable from every tested network. |
| 2026-10-16 04:45 | Bhavik approved pending entry 77 (B17.11 follow-up). No backend change | Flow doc A8 is now Admin: servers — Organizations screen, flow step, route /admin/organizations and the admin sidebar item removed; A2 user detail keeps the Organizations tab, read-only (the only admin view of organizations in v8). Stale "59 permissions / 34 sidebar screens" notes now say 53 / 33 after B17.11 on Permissions, Roles, Routes, Phases, Missing backend, API architecture and FE: Admin; 17.11 conflict callout notes 17.11 is Not in V8 (no decision on deleted servers). Admin Servers screens unchanged. Other pending items (D-58–D-62, D-60, D-61, Login-as-user return) untouched |
| 2026-10-23 11:04 | Pair2: 9.6 Deleted servers list: the managed / self-managed filter is dropped — both kinds are listed together. Pair1 unchanged | FE: Server screens 9.6 row; pending 95 note corrected |
| 2026-10-28 11:19 | Pair1: activity log as V7 — server only: application.activity and the app activity log removed; the server's Activity Log now shows Central's entries for the server, its shares and its apps, and opens while the server is down. Pair2 unchanged | FE: Permissions screens row. No conflict (the fixed app menu has no Activity Log). Pending 112 |
| 2026-10-28 10:04 | Pair1: 4.6 — server.share view now only lists who the server is shared with (manage shares); a shared user never gets server.share. Pair2 unchanged | FE: Permissions screens server.share row. Pending 106 note |
| 2026-10-28 08:49 | Pair1: admin settings come only from the saved rows (no defaults); Billing Settings is its own admin screen (company details, tax %, min and max recharge — the $4,000 limit is gone, USD→INR rate updated daily); checkout unavailable (503) until it's saved; managed-server days are empty until the admin saves them (no countdown starts). Pair2 unchanged | FE: Billing screens 6.4; FE: Admin screens 17.17. The two docs now differ on the $4,000 maximum. Pending 111 |
| 2026-10-27 13:19 | Pair2: install Retry removed; a failed install deletes the server (as V7, API contract change): Retry APIs 66/70/75 → 404; every install failure soft-deletes the server (not listed, not restorable, IP free; cloud/managed machine deleted at the provider); opening it answers 410 server_install_failed with the failure details. Pair1 unchanged | FE: Server create screens warning callout + 8.9 row. No conflict. Pending 110 |
| 2026-10-27 11:49 | Pair1: admin sidebar — Customers → User Management; new Managed Servers section with Server Plans (moved from Integrations, new path) and new Managed Server Settings (API166: unpaid-credit due / retention / deletion days, normal + trial, 1–30). Pair2 unchanged | FE: Admin screens sidebar note + 17.18 row; FE: Billing screens 6.12 days note. Linked to pending 96 (your OK on admin managed-server screens). Pending 109 |
| 2026-10-27 11:04 | Pair2: panel administrator (local commit): on every OSS install path the panel admin fields are optional; left empty, Central generates the first administrator and returns it once; the username is no longer kept or returned on the Server object. Pair1 unchanged | FE: Server create screens section B note. No conflict. Pending 108 |
| 2026-10-27 10:34 | Pair1: server & application sidebars as OSS (API164–165): menus list only the screens the server's stack / app's framework has and the user may view. Permissions split as OSS's sidebars: server.runtime → server.php + server.node; application.security → + firewall, bot-blocker, fail2ban; application.clone split from staging; new application.compose, application.magic-login. Pair2 unchanged | FE: Permissions screens keys; FE: Server screens menu note. No conflict. Pending 107 |
| 2026-10-27 08:34 | Pair1: change-log only — ordinary API routes now allow 240 requests a minute per user (temporary, until limits follow the plan); sign-in, 2FA, reset and other guess-protection limits unchanged. Pair2 unchanged | No screen change (the existing "too many requests — try again shortly" handling stays). No pending entry |
| 2026-10-27 08:04 | Pair1: 4.6 / 4.9: new permission server.share — the owner or a member with it (manage) shares a server (was owner only); application.database removed (deleting an app with its databases needs server.database manage); server.resize listed. 8.2: Hetzner sizes with another storage type aren't offered; Central follows the provider's real size and price if they differ. Pair2 unchanged | FE: Permissions screens keys; FE: Organization screens Share server "Who". No new conflict (D-65 Accept still open). Pending 106 |
| 2026-10-27 07:19 | Pair1: 8.2 Managed servers, Step 4 built (API159–163) — managed servers now complete: power state + power on/off (refused while paid credits ≤ 0), resize with new permission server.resize (DigitalOcean/Hetzner: clean shutdown + optional permanent disk growth; Vultr: own upgrade list; Linode: cold/warm), new price only after the provider finishes; admin provider reboot. Pair2 unchanged | FE: Server screens 9.3 / 9.4 rows. No new conflict (D-36 is only about creating). Pending 105 |
| 2026-10-27 06:49 | Pair2: review fixes (Jayshree, local commits): unpaid PayPal/Instamojo checkouts expire after 24 h; amount out of range → 422; 2-letter country code; first verification through Google/GitHub link or reset drops the earlier password and sessions; cloud account in use can't be disconnected (409); non-owners grant only permissions they hold (403); admin can't delete a user who owns servers (409); delete protection (423) on all 8 app delete actions. Pair1 unchanged | FE: Billing screens 6.4; FE: Integrations 5.5 note; Roles & permissions note; Edge cases #35. No conflict. Pending 104 |
| 2026-10-27 06:04 | Pair1: 6.12 / 6.13 Managed servers, Step 3 built — negative-balance process without emails (Phase 11): from the expire date empty servers are deleted and the rest powered off (panel not answering → power off); from the deletion date the rest are deleted (not restorable); back above 0 clears the dates, no automatic power-on. Pair2 unchanged | FE: Billing screens 6.12 / 6.13 rows. No conflict. Pending 103 |
| 2026-10-27 05:04 | Pair1: 6.10 / 6.11 Managed servers, Step 2 built (API157–158): hourly charging from the owner's paid credits, from 10 min after Ready; deleting charges the last full hours; the payer's charges list (owner only, year/month/search, totals) and per-server usage. Pair2 unchanged | FE: Billing screens 6.10 / 6.11 rows. No conflict (existing managed servers still bill hourly). Pending 102 |
| 2026-10-27 04:49 | Pair2: status only — 6.7 History & receipts now pushed (Phase 6 status: 6.1–6.5 and 6.7 built). Pair1: 8.2 a failed managed install deletes its VM automatically (as V7); the server stays Failed and can only be deleted (no Retry) | FE: Billing screens 6.7 build note; FE: Server create screens 8.2 row. Pending 100 and 101 notes |
| 2026-10-27 04:19 | Pair1: 8.2 / 6.9 Managed servers, Step 1 built (Vishal, API154–156): create form from the visible admin price list (size, name, Ubuntu, stack, optional SSH key), owner's paid credits ≥ one month ("please add $X"), verified owner email, trial = popular sizes only; no managed-server limit (6.4 +3 removed too); Delete always deletes the VM; billing starts 10 min after Ready (billing, negative balance, power/resize/reboot later). Pair2 unchanged | Conflict D-36 (Bhavik: users can't create managed servers). FE: Billing screens 6.4 / 6.9 rows + return-page step; FE: Server create screens 8.2 row; Open questions D-36 update. Pending 101 |
| 2026-10-26 17:34 | Pair2: 6.7 History & receipts built (local commit, not pushed; API89–94): own payment history (status filter, continue link while ready, receipt flag), receipt for succeeded payments (frozen billing/company details, INR block for India, export block with LUT outside India; 6-digit number for now), admin GST LUT periods (list/add/change/delete, no overlaps). Pair1 unchanged | FE: Billing screens 6.7 rows; FE: Admin screens new Admin — GST LUT periods section. Pending 100 |
| 2026-10-26 11:34 | Pair2: +3 managed-server limit per payment removed (Jayshree, 6.4 / 6.9): payments no longer raise any limit; the managed-server limit comes only from the admin setting and admin changes. Pair1 unchanged | Billing 6.4 row and FE: Billing screens 6.4 row updated (no "+3" message after payment). No flow-doc impact (managed servers can't be created by users) |
| 2026-10-26 08:04 | Pair2: status only — 4.6 Share server and 9.2 Shared with me now pushed to GitHub (API86 removed; one shared server opens with View server 64). Pair1 unchanged | fe-organization-screens / fe-server-screens build notes; D-65 still open |
| 2026-10-26 07:04 | Pair2: 4.6 Share server built (API79–88, local commit, not pushed): owner only; email + per-feature view/manage (server + app permissions); no accept step (existing account = access at once, new email = sign-up link); resend/remove; recipient can leave; membership and sharing never combine. 9.2 Shared with me built (list, filtered menu, leave). Pair1: 9.8 Disconnect removed (as v7) — one Delete; endpoint 404 | Conflict D-65 (Bhavik: sharing needs Accept). FE: Organization screens 4.6 row + new Share server section; FE: Server screens 9.2 built, 9.8 struck out; Open questions D-65 added. Pending 98, 99 |
| 2026-10-26 05:19 | Pair1: 17.7 admin deleted-server restore built (API153): admins restore an organization's deleted server with the same checks as the owner restore (9.6); permission users.organizations.deleted-servers manage; admin server rows gain restorable; no admin delete-permanently, no email. Pair2 unchanged | Conflict D-63 (Bhavik: deleted servers + restore not in V8). FE: Admin screens D-63 note and Open questions D-63 updated; no screen written. Pending 95 note |
| 2026-10-26 04:34 | Pair1: 17.24 System Add-ons built (Vishal, API146–152): admins create add-ons (recurring with 1–12 billing cycles, price = base price × months; or lifetime one-time price), copy discounts from discount promo codes, turn on/off, delete (name stays taken). Users list active add-ons (API152, no discounts). One sidebar item replaces the 4 add-on screens; permission system-addons (51 permissions, 22 screens). Buying comes with billing. Pair2 unchanged | FE: Admin screens: sidebar note, Add-ons row, new section Admin — System Add-ons (list, create/edit fields + rules, live cycle price, discount copy note, delete type-to-confirm, messages, user catalogue). Pending entry 97 |
| 2026-10-23 10:49 | Pair2: 9.6 Deleted servers list now shows every deleted server whose install finished, each marked restorable or not, with a managed / self-managed filter (Jayshree, as v7). Pair1 unchanged | FE: Server screens 9.6 row; still Conflict (D-63), no screen written. Pending entry 95 note |
| 2026-10-23 10:04 | Pair1: 17.18 Server Plans built (admin side, API139–145): ServerAvatar's own provider accounts for managed servers (DigitalOcean, Vultr, Linode, Hetzner), key checked with the provider, regions/sizes live, per-region price list (USD), popular/recommended flags, unticked sizes hidden. Pair2: 9.6 Deleted servers & restore now pushed | FE: Admin screens: new section Admin — Server Plans (providers list, connect modal, per-region plans editor, messages, currency note); 17.18 row corrected (own accounts, does not change the user wizard). fe-server-screens 9.6 marked pushed. Pending entry 96 (+ 95 note) |
| 2026-10-23 09:34 | Pair2: 9.6 Deleted servers & restore BUILT (on main, not pushed): organization owner only; delete keeps the panel link so restore is one click; Delete permanently (owner only); restore refused if the panel is offline / key removed / panel already in Central; not restorable: deleted at provider, managed, never-Ready installs; plan/limit checks wait for Phase 7. Pair1 unchanged | Conflict with Bhavik's 2026-10-07 rule (deleted servers + restore not in V8). FE: Server screens 9.6 row + conflict callout updated; Open questions D-63 widened to user side. No screen written. Pending entry 95 |
| 2026-10-23 06:34 | Pair1: admin Referral Settings merged into Referrals — one sidebar item /admin/referrals with tabs Referred users · Settings (/admin/referrals/settings); permission referrals.settings removed (settings use referrals view/manage); API108–109 unchanged. 54 admin permissions, 25 sidebar screens. Pair2 unchanged | FE: Admin screens sidebar note + Referral program block moved to the Referrals Settings tab; FE: Referral 18.9 row. Pending entry 94 |
| 2026-10-23 05:17 | Pair1: 17.13 Move a server built (Vishal, API138 POST /admin/servers/{id}/move): one action for both V7 transfers — another organization of the same owner, or account email + organization. Cloud link cleared → Custom server; managed and still-setting-up servers refused (409). Permission servers.move. Pair2 unchanged | FE: Admin screens: new section Admin — Move a server (modal fields + rules, confirm naming both sides, cloud→custom warning, 422/409/404 messages, i18n admin.servers.move.*); 17.13 row marked built. Pending entry 93 |
| 2026-10-23 04:32 | Pair2: build status checked in the code — every feature row now ends with ✅ built & pushed / 🟡 partly built / ⏳ pending, plus one build-status line per phase. Pair 2 now also records Pair 1's 2026-10-15/17 changes: 4.3 members added directly (no invitations), 4.7 ownership transfer removed, 2.6 follows 4.3, 4.9 permission renames, 5.2 same credentials once per organization. On hold: 6.6–6.13 and Phase 7 (Jayshree 2026-10-12). Pair1 unchanged | No new screen rules — all already on the spec pages from the Pair 1 syncs (2026-10-15 11:32, 10-17). Pending entry 75 (D-60 invitations / D-61 ownership transfer) updated: both backend docs now agree, so this is still waiting on Bhavik's decision |
| 2026-10-22 11:17 | Pair1: 17.12 Part 2 built — admin live server screens API120–137 (check now, overview, services + actions + config test, applications, databases, system users + SSH on/off, reboot/cancel, logs). New admin permissions servers.databases / system-users / logs (55) | fe-admin-screens: new section Admin — Servers Part 2. Pending entry 92 |
| 2026-10-22 10:17 | Pair1: Phase 17 status line refreshed; admin user → organization Servers and Deleted servers tabs marked built (charges, subscription, backups, restore still to come). Status only | fe-admin-screens 17.11 note |
| 2026-10-22 08:02 | Pair2: 8.1 start-up script marked ✅ Built & pushed (status only) | No screen change |
| 2026-10-22 07:47 | Pair2: 8.1 cloud servers start the panel installer from the provider start-up script at first boot (SSH fallback after 5 min); IP may show while Creating; new failure_detail code user_data_pending | fe-server-create-screens (cloud progress/failed note); entry 90 note |
| 2026-10-21 15:16 | Pair1: admin Server Plans moved from Billing & Plans to the Integrations sidebar section (same screen, permission, URL) | fe-admin-screens Plans row note; entry 91 note |
| 2026-10-21 11:46 | Pair1: admin Integrations → Cloud Platforms removed (never built; no OAuth in V8). SA's managed-server provider accounts stay in Server Plans (no Lightsail). 52 permissions, 26 screens | fe-admin-screens Integrations row; entry 91 note |
| 2026-10-21 11:31 | Pair1: admin sidebar title "Cloud Provider Price List" → "Server Plans" (title only; permission + URL unchanged) | fe-admin-screens Plans row note; pending entry 91 note |
| 2026-10-21 11:00 | Pair1: admin sidebar regrouped into 11 sections (Dashboard · Customers · Roles & permissions · Servers · Billing & Plans · Marketing · Integrations · System Addons · Settings · Admin activity · Error monitor); one-screen sections have no heading; group keys renamed. Removed Plan overview, ServerAvatar DNS, White label DNS (53 permissions, 27 screens) | fe-admin-screens: regroup note, DNS + Plan overview struck out. Pending entry 91 |
| 2026-10-21 10:00 | Pair2: 8.1 cloud install fixes — self-signed panels now reach Ready; new Failed reason ssh_login_refused; Retry after a finished install only re-checks the panel; new failure_detail on failed servers and detail on panel errors (real cause, translated); new 502 oss_tls_changed | fe-server-create-screens (cloud Failed state), fe-server-screens (common error rules). Pending entry 90 |
| 2026-10-21 09:30 | Pair1: admin Alerts permission + /admin/alerts sidebar screen removed (never built; 56 permissions, 30 sidebar screens). Admin Slack webhook and users' server alerts stay | fe-admin-screens: Alerts group row struck out, "do not build". Pending entry 89 (flow doc A-side sidebar + server rows mention Alerts) |
| 2026-10-17 12:13 | Pair1: Integrations is back as a permission group (organization.integrations, heading only); Cloud Providers = organization.integrations.cloud-providers; Git / storage will be .git / .storage. Pair2 unchanged | Integrations/Permissions/API pages updated; naming question 87 mostly resolved (only the url path differs). Deploy still blocked (host key) |
| 2026-10-17 10:58 | Pair1 navigation notes: Servers = one server permission (link shown when org menu has server); account menu fixed in the frontend, no account permissions/menu API. Pair2 unchanged | Navigation note on Routes + Permissions pages; Servers path difference vs Bhavik's /servers noted under D-55. No pending entry. Deploy still blocked (host key) |
| 2026-10-17 10:28 | Pair1: organization permission organization.billing → organization.usage-summary (title 'Usage Summary', owner-only; billing + plan are account-level as V7). Pair2 unchanged | Permission name updated on Billing / Permissions / Roles / Open questions / V7 migration pages; Billing note. Pending88. Deploy still blocked (host key) |
| 2026-10-17 09:43 | Pair1 correction: the renamed permission is organization.cloud-providers (title 'Cloud Providers', url /organizations/{id}/cloud-providers), not cloud-platform. Pair2 unchanged | Names corrected on Integrations / Permissions / API pages; pending 87 note appended. Deploy still blocked (host key) |
| 2026-10-17 09:28 | Pair1: organization permission organization.integrations → organization.cloud-platform (title 'Cloud Platforms', menu url /organizations/{id}/cloud-platforms); Git + backup storage to get own permissions later. Pair2 unchanged | Permission name updated on Integrations / Permissions / API pages; naming difference vs Bhavik's 'Integrations' paths noted under D-55. Pending87. Deploy still blocked (host key) |
| 2026-10-17 07:43 | Pair2 Phase 9 Step 0: server-panel groundwork — Ready-only (409), permission per screen (incl. Docker, panel update, service monitoring), OSS data as-is, oss_message errors. Pair1 unchanged | 'Server panel — common rules' block on the server screens page; status lines. Pending86. Deploy blocked (doc server host key changed) |
| 2026-10-17 07:28 | Pair1 B17.12 admin Servers Part 1 built (API114–119): list/view/edit + user/org Servers and Deleted servers tabs; servers soft deleted. Pair2 unchanged | New Admin 'Servers Part 1' spec; Deleted list kept under D-63 conflict; status lines. Pending85. Doc server reachable again — published all queued changes |
| 2026-10-17 06:43 | Pair2 8.3: ipinfo.io used without a key; the ipinfo token in admin integration keys is removed. Pair1 unchanged | Admin note corrected (no ipinfo field). No flow change. Doc server still unreachable |
| 2026-10-17 04:47 | Pair1 B17.19 General settings built (API103–113): display message (+ display_message on public API97), trial mode on/off, referral settings, Slack webhook + test; user settings / temporary domain / support email removed. Pair2 unchanged | New Admin 'General settings' spec; user banner note; trial toggle marked not built (D-56 conflict); status lines. Pending84. Doc server still unreachable |
| 2026-10-16 11:59 | Pair2 8.3: SSH-unreachable error is the plain V7 message (no Central IP); ipinfo.io token moved to admin integration keys. Pair1 unchanged | Root-password error note; admin integrations note. No flow change. Doc server still unreachable |
| 2026-10-16 10:59 | Pair2 Phase 8 status marks: 8.1 (5 providers), 8.3–8.5, 8.7, 8.9–8.12 built & pushed; 8.8 plan/limit wait for Phase 7, provider-enabled waits for admin panel; 8.2 + 8.6 pending. Pair1 unchanged | Status lines in Servers/Phases/Missing-backend/Add-a-server. No flow change, no new pending entry |
| 2026-10-16 10:44 | Pair2 8.6/12.12 Lite: now gets the OSS panel (replaces V7 agent), limited login = Phase 12 Control Panel user; built after Phase 10 + 12. Pair1 API102: admin user → organization → Members tab (view only) | 8.6 row updated (no screen yet); admin Members-tab note. Pending83. Doc server still unreachable |
| 2026-10-16 09:59 | Pair2 8.1 Lightsail built — all five cloud providers done (region + availability zone, no static IP). Pair1 B17.23 Error monitor built (API99–101: list/view/resolve, 2-day retention) | Cloud-server spec: Lightsail zone + IP note, no 'Coming soon'; new Admin 'Error monitor' spec; status lines. Pending82. Doc server still unreachable |
| 2026-10-16 09:29 | Pair2 8.1 Linode built (root password field on API74, strong rule; GPU/sold-out plans hidden). Pair1: admin actions (ban, delete, 2FA/IP off, login as) now allowed on own account + other admins; admin_target_protected removed; login_as_self refused; lockout guard kept | Cloud-server spec adds Linode + root password; admin page note supersedes 'protected admin' rules. Pending80 + 61/62/66 follow-up. Doc server still unreachable |
| 2026-10-16 08:59 | Pair1 API98 Admin edit a user: profile, email (immediate), password, role, admin role, status of any account incl. own/other admins; lockout guard. Pair2 unchanged | New Admin 'Edit a user' spec (About-you fields left out per D1); status lines. Pending81. Doc server still unreachable |
| 2026-10-16 07:59 | Pair2 8.1: Hetzner built on the same cloud APIs (EUR prices; every size now has a currency; Arm CAX sizes). Pair1 unchanged | Cloud-server spec: Hetzner added, size prices shown with their currency. Pending80 note appended |
| 2026-10-16 07:14 | Pair2 8.1: Vultr now also works on the same cloud APIs (name rule per provider: no dots for Vultr); 8.1 pushed when all providers are done. Pair1 B17.17: only one GST number (V7's second new_gst_number not in v8) | Cloud-server spec covers DigitalOcean + Vultr; site-settings billing has one GST number. Pending80 note appended. Doc server unreachable at 06:59 — published with this deploy if reachable |
| 2026-10-16 06:59 | Pair2 8.1 DigitalOcean built (API71–75 + delete_at_provider on 67). Pair1 B17.17 Site settings built (API93–97: basic + billing details, tax % = checkout tax, public settings before login, custom header/footer code) | New 'Cloud server — DigitalOcean' spec; new Admin 'Site settings' spec; D-64 (custom code injection) open question; status lines. Pending80, flow doc untouched |
| 2026-10-16 05:44 | Pair2 8.3 root password built (API69–70): public IPv4 + SSH port + root password, Ubuntu/CPU check, same installer progress, Retry asks password again, one server per IP; install APIs renumbered (66 retry, 67 delete-for-all, 68 report). Pair1 unchanged | New 'Root password — built' spec; install-command API numbers fixed; status lines. Pending79, flow doc untouched, no new conflict |
| 2026-10-16 05:29 | Pair1 API59: GET /admin/menu now returns admin_role + permissions [{name, view, manage}] (replaces what /admin/me gave). Pair2 unchanged | D-62 answered → moved to Answered; admin warning callout rewritten (hide tabs/buttons by permission again); status notes updated. Pending76 open question resolved (note appended) |
| 2026-10-16 04:59 | Pair2 8.4 rename: server response field install → installation_status (API62–67). Pair1 unchanged | Install-command spec field names updated. No flow change, no pending entry, no conflict |
| 2026-10-16 04:44 | Pair1 B17.11 revised: organization tabs (members, servers, charges, deleted servers + restore, subscription, backups) moved under Users → user → Organizations (users.organizations.*); 59 permissions, 33 screens; endpoints later (members now, Phases 7–8). Pair2 unchanged | 17.11 row rewritten; status notes updated; Conflict D-63 (deleted servers + restore vs Bhavik's not-in-V8 rule). Pending78 (replaces 77) |
| 2026-10-16 04:29 | Pair1 B17.11 admin Organizations removed from v8 (Vishal): use Users → user → Organizations (API69); 7 organizations* admin permissions + sidebar item removed (53 permissions, 33 screens). Pair2 unchanged | 17.11 row marked Not in V8; catalog counts noted on admin/permissions/routes/phases/missing-backend. Pending77, flow doc untouched, no conflict |
| 2026-10-16 04:14 | Pair1 B17.1/17.2: GET /account/admin-access and GET /admin/me removed; admin flag only in login/profile, sidebar via /admin/menu; admin role + permissions no longer exposed. Pair2 unchanged | Admin entry steps rewritten (profile flag + /admin/menu), API table rows struck, status notes; D-62 open question (no view/manage info for in-page buttons). Pending76, flow doc untouched |
| 2026-10-15 11:32 | Pair1 (Vishal, 'as v7'): invitations removed → Add members (existing account joins at once, new email = pending member joined on sign-up; old API26–32b gone) and ownership transfer removed (4.7 'Not in v8', API39–43a + ownership_transfer gone). Pair2 8.4 simple flow: no 'command again' API, never-run command hidden + auto-removed after 24 h, Retry only for Failed | Conflict D-60 (vs Bhavik D4 'invite must be Accepted') and D-61 (vs settled 'transfer ownership kept') callouts on Organizations B/D + list section; open questions; D-58 marked moot-if-accepted. Install-command spec updated. Pending75; pending 70/71 on hold |
| 2026-10-15 10:47 | Pair1 B17.20 Part 2: admin SMTP + test email built (API89–92): saved vs server-default settings, write-only password, test email, reset to defaults; all admin integration keys now in one store (backend-only). Pair2 unchanged | Admin Integration keys: new SMTP tab spec; 17.20 status; status lines. Pending74, flow doc untouched, no conflict |
| 2026-10-15 10:17 | Pair2 8.4/8.7: Docker added to stacks (docker, as OSS); install-command API no longer checks verified email — 'frontend checks it'. Pair1: profile returns role + is_administrator for admins | Install-command form/stack list, 8.7 row, permission note; D-59 open question (frontend-only email check); admin-link note. Pending73, flow doc untouched |
| 2026-10-15 09:47 | Pair2 Phase 8 Step 2: 8.4 install command built (33bd7c0, API65–69): name + stack (no IP), official OSS command, installer reports steps, Central checks panel → Ready + 'create admin account'; 24 h / 30 min failures, Retry/Delete; needs OSS installer update. Force cleanup dropped (8.7). Server object gains panel_url (web address), failure_reason/message, install. Pair1 unchanged | New 'Install command — built' spec; 8.4 + 8.7 rows; status lines. Pending72, flow doc untouched, no conflict |
| 2026-10-15 07:02 | Pair1 B4.7: organization responses carry ownership_transfer (sender/recipient only, pending + 7 days after end); new recipient Decline (API43a, no confirmation, owner emailed). Pair2 unchanged | Organizations: new 'Decline transfer' flow + 'Transfer status on organization cards' (badges/banners from ownership_transfer). Pending71, flow doc untouched, no conflict |
| 2026-10-15 06:02 | Pair1 B2.2: verified email no longer needed at organization level except ownership transfer — invitation send/resend, in-app Accept/Decline (32a/32b) and pending rows work while unverified; risk of accepting someone else's invitation noted, 'guarded by the frontend'. Pair2 unchanged | Organization list pending card now uses 32a/32b Accept/Decline (was stale 'email link only'); eligibility updated; Conflict D-58 security callout + open question; auth unverified note. Pending70, flow doc untouched |
| 2026-10-14 11:46 | Pair2 8.5 pushed (up to 5be6dec); response field facts → system_info. Pair1 B17.20 Integration keys Part 1 built (API82–88): social login, Turnstile, payment gateways; secrets write-only; SMTP next | Server details uses system_info; push status in status lines; new Admin Integration keys spec (tabs, write-only secrets, webhook URLs); 17.20 row. Pending69, flow doc untouched, no new conflict |
| 2026-10-14 11:31 | Pair2 8.5 rename: request/response field panel_url → api_url (servers API62–64). Pair1 unchanged | Connect-a-panel field/error/list wording now uses api_url. No flow change (pending 68 already says 'API address'); no new pending entry, no conflict |
| 2026-10-14 11:16 | Pair2 8.5 changed (Jayshree): Connect accepts the API address (https://api.…) + token only; the panel web address is refused (oss_not_a_panel). OSS team will show the API address next to the token. Replaces the 10:31 'either address' rule. Pair1 unchanged | Connect-a-panel field renamed 'API address' + help/error text; 8.5 row; status lines. Pending68 (supersedes the address part of 67), flow doc untouched, no new conflict |
| 2026-10-14 10:31 | Pair2 8.5 fix: connect accepts the panel address or its api. address; new error oss_not_a_panel; tested live on an OSS test server. Pair1 B17.15 admin Promo codes built (API78–81): list/create/on-off/soft delete, no edit, cohort→customer_type | Connect-a-panel field help + error list; new Admin Promo codes spec; 17.15 row; billing 'cohort' wording; status lines. Pending67, flow doc untouched, no new conflict |
| 2026-10-14 10:16 | Pair2 Phase 8: Step 0 pushed (2899bd1); 8.5 Connect an OSS panel + server list/view built locally (API62–64; public HTTPS, health, token, not already connected; plan limit pending). Pair1 B17.10 Login as user built (API77, manage-only, no password/2FA/IP step, admin log only) | New 'Connect a panel — built' spec (form, errors, list, details, statuses) in Add a server; new Admin 'Login as user' spec with open return-to-admin question; status lines in Servers/Phases/API/Routes/Missing-backend. Pending65–66, flow doc untouched, no new conflict |
| 2026-10-13 04:49 | Pair2 Phase 8 Step 0 built locally (4a375e9, not pushed): servers foundation, OSS API client, server activity events; account/organization delete refused while servers exist. No server endpoints yet; 8.8 plan checks still pending. Pair1 unchanged | Add-a-server/Servers/Phases/Missing-backend status; servers-exist refusal note on Delete account (3.7) and Delete organization (4.2). Pending64, flow doc untouched, no new conflict |
| 2026-10-12 12:48 | Pair2 Phase 8 plan: Pair 2 builds Servers in steps (0 foundation → 8.5 → 8.4 → 8.1 → 8.3; 8.2 + 8.6 later); 8.8 plan-active/server-limit checks ⏳ skipped until Phase 7. Pair1 unchanged | Add-a-server build-order note + 8.8 pending marker; Servers/Phases/Missing-backend status lines. Pending63, flow doc untouched, no new conflict |
| 2026-10-12 12:33 | Pair1 B17.7 Admin user details backend built (API69–76): organizations, login history, account activity, 2FA status/turn off (codes counted only), IP whitelist view/turn off/remove IP; new users.activity permission; servers tab waits for Phase 8. Pair2 unchanged | New Admin user-details tabs spec; 17.7 row status; account activity by-admin badge note; routes/phases/API/missing-backend updated. Pending62, flow doc untouched, no new conflict |
| 2026-10-12 11:18 | Pair1 B17.6 Admin users backend built (API61–68): list/counts/view/create/ban/unban/verify/delete, deleted + referred users; statuses active/pending/banned (no locked); self/administrator protected. Users soft deleted (also B3.7, no visible change). Pair2 unchanged | New Admin Users screen spec (list, counts, create modal, ban/verify, delete type-to-confirm, deleted/referred lists, states); 17.6 row status corrected; routes/phases/API/missing-backend updated. Pending61, flow doc untouched, no new conflict |
| 2026-10-12 10:48 | Pair2 B6.5: auto-recharge not available for India (billing country or India-issued card, as V7); India mandate API62 removed (e65e8c3); card APIs answer directly 200/201, 202+polling only when Stripe is slow (0ff3da9); 6.4/6.5 pushed, still not activated. Pair1 unchanged | Billing cards: 2-call add-card path, 51/52/57 as fallback; auto-recharge not_available_india hides the option + 422 on turn-on; India mandate bullet replaced. Status lines in Billing/API/phases/missing-backend updated. Pending60 (flow doc untouched), no new conflict |
| 2026-10-12 09:50 | Pair1 B17.4 Admin activity backend built/API60: separateadminfeed,actor/target snapshots,translatedrows/filterdropdowns,type/action/admin/subject/dates/namesearch,default10max50. Sharedaccount/orgunchanged | Updated Admin activity/table/error/permission/privacy/filter states,Audit/API/routes/readiness. Pending59,flowuntouched,no newconflict. No new final test-count inferred;Pair2unconfirmed,B17.5+wait |
| 2026-10-12 09:20 | Pair2 B6.5 locally built f2053a11740 tests/Pint/PHPStan reported passed, not pushed/activated;Pair1 B17.3 menu built,59 permissions34 screens,queue-size removed(Horizon) | Billing readiness/provenance updated;Admin menu/group/order/role-empty/error states, catalog counts/removal and API/routes/readiness aligned. Pending58,entry57readiness follow-up;flow unchanged,no new conflict. Menu destinations still unbuilt;activation blockers remain |
| 2026-10-12 08:21 | Pair1 B17.2/17.2a roles/catalog/assignments backend BUILT1545tests26livechecks reported; Pair2 B6.5 cards/auto-recharge IN PROGRESS, contracts49–62, safety fixes/final tests pending, no activation | Admin editor/ability/lockout and Billing cards/setup/default/remove/autorecharge/auth/cancel/mandate drafts specified; API/readiness/roles updated. Pending56–57,flow untouched,no new conflict; legal/provider/frontend/scheduler proof remain blockers |
| 2026-10-12 08:05 | B17.2a clarification: Admin roles & permissions now view+manage; view reads roles/permissions/assignments, manage creates/edits/deletes/assigns. Login as user still manage-only; Users-manage includes neither | Updated Admin screen/table, permission-matrix shapes and Roles spec; Pending55, flow untouched. Requirements only, no new conflict, exact admin APIs/catalog/safeguards still wait |
| 2026-10-12 07:05 | Pair1 B17.1 administrator backend access built: own discovery/API49, guarded identity/API50, normal login preserved; no automatic promotion or permissions/sidebar.1501tests9118assertions,36livechecks backend-reported. Top status corrected to implementation tracking | Admin entry/card/states/permissions/no-store/revocation specified; Admin/API/routes/readiness updated. Pending54, flow untouched; no new conflict. B17.2 onward remain unbuilt, Pair2 availability unconfirmed |
| 2026-10-10 15:01 | Pair2 B6.4 Add credits built locally/not pushed/not activated, API43–48 quote/checkout/status/confirm/free codes, verified credit/+3, unresolved-payment deletion409;1605tests9194assertions backend-reported. Top status now development in progress | Updated Billing/screens/API/readiness/Account/D-22; hosted-return/status/error/test/recovery/free-code states, real activation blockers and no receipts/history promises. Pending53, flow untouched; no new conflict. Instamojo merchant proof+all gateway keys/webhooks/return still needed |
| 2026-10-10 11:44 | Pair2 pulls organization filters a7aefc9 and pushes Billing B6.1–B6.3 through2ac99ce; local/GitHub synchronized,1405 tests8652 assertions+quality/build reported passed | Organization code availability and Billing/API/readiness/provenance updated; current commits35e5da8/b27bf09/2ac99ce. Existing pending48/50–52 availability follow-up, no new screen/conflict/approval; flow unchanged |
| 2026-10-10 11:14 | B6.3 finalization/verification only: local0fd63c0, independent final review passed;1318 tests/8332 assertions, quality/build/fresh install reported passed; no push. Internal insertion/timestamp safeguards fixed | Billing screen/provenance notes updated; API42 reread, no visible contract delta. No new proposal/conflict, Pending52 unchanged, flow untouched. Payments/imports unbuilt and host scheduling unverified |
| 2026-10-10 10:45 | Pair2 B6.3 wallet locally built/not pushed: USD exact-string balances/API42, promo→free→paid, no partial spend, UTC expiry, negative-paid deletion409;1314 tests8299 assertions backend-reported | Updated Billing/screens/API/readiness/Account deletion; D-22 walletUSD settled, paymenttax still open. Pending52, flow unchanged; no new conflict. No public mutations/payment/import/history; host scheduling unverified |
| 2026-10-10 09:59 | B4.1 verification only: exact recipient matching fix rejects accent-insensitive lookalikes;1122 tests/6358 assertions and23 live checks backend-reported passed; no rule/contract delta | Added Organization screen verification/provenance, refreshed source hash/time. Pending51 already covers eligibility; no new proposal/conflict, flow untouched. Notification logging issue still deferred |
| 2026-10-10 09:45 | Pair1 B4.1 list filters published: literal search, all/mine/invited, eligible pending invitations, joined/pending minimal metadata and no pending access; joined-only auth/profile unchanged | Updated Organizations/screens/API; pending cards stay out of switcher, acceptance only via existing email link, ownership filter follows current owner. Pending51, flow unchanged; no new conflict. Pair2 newer-list availability unconfirmed |
| 2026-10-10 08:30 | Pair2 pulls provider B5.1–B5.5 through cf36220; billing commits rebased29b3379/4d22ce2, not pushed;1211 tests/7473 assertions and quality checks backend-reported | Corrected Integrations/Providers/API/readiness code availability and Billing provenance. Pending43–50 follow-up only; no new screen/rule/conflict. Disconnect guard missing; flow unchanged |
| 2026-10-10 08:15 | Pair2 B6.2 billing details locally built, not pushed, commit798d798;818 tests/4725 assertions backend-reported. Own-account GET/PUT full form, optional city, separate billing email; no providers/receipts/6.3+ | Updated Billing/screens, API, Phases/Missing backend and safe Activity; real form/permissions/errors incl unavailable-reference state, no false owner gate. Pending50, flow unchanged; no new conflict. Country/region catalog not published |
| 2026-10-10 07:45 | Pair1 B5.5 Disconnect endpoint built partially; selected Central account deletion/safe activity, snapshot response/repeat404, shared four-mutation limiter. Server-usage blocker/warning remain Phase8 | Updated Integrations/Providers/API/readiness/Audit; confirmation, no upstream revoke/server deletion, noUndo/reconnect and stale-view outcomes. Pending49, flow untouched; no new product conflict, explicit missing safety dependency. Included concurrent backend logging-security fix for encoded routes;910 reported tests/5607 assertions, no screen change |
| 2026-10-10 07:29 | Verification/provenance only: Pair2 B6.1 local commit dffa45d,726 tests/4070 assertions, Pint/PHPStan, live authorization and fresh Composer install reported passed; clean tree/no push | Recorded backend-reported proof; no contract/screen change, no new flow proposal or conflict. Local-only/not-pushed status and pending48 retained; flow untouched |
| 2026-10-10 07:15 | Primary Pair2 B6.1 gateway setup/list locally built, not pushed; enabled provider/name/mode only, no real credentials;6.2 onwards/admin screens/checkout/capture/webhook verification deferred | Updated Billing, Admin gateway readiness, API, Phases/Missing backend; metadata empty/single/multiple/test states, no invented payment endpoint. Pending48, flow untouched; no new conflict |
| 2026-10-10 07:00 | Pair1 B5.4 on-demand Check built;200 valid/rejected status,503 transient/unreadable preserves saved state,409 concurrency refusal;shared10/min Connect/Edit/Check;status-change activity only | Updated Integration/Provider/API/Audit/readiness specs, distinct outcomes and Edit repair. No automatic checks or genuine-provider success claimed. Pending47, flow unchanged; no new conflict/open decision. Pair2 unchanged |
| 2026-10-10 06:30 | Pair1 B5.3 Edit built: optional rename/complete credential replacement, immutable provider/org/status; rename preserves secrets/status;422/503 no changes;409 concurrent-change refusal. Connect/Edit share10/min/user; safe edit activity | Updated Integrations, Providers, API, Phases, Missing backend and Audit log. Real PATCH contract and form/loading/error/conflict states; no secret prefill or blind overwrite. Pending46; flow unchanged. No new conflict; real-provider success remains mocked/unverified, Pair2 code availability not inferred |
| 2026-10-10 05:59 | Verification-only update: Pair1 B5.2 reported Pest count658→662; no contract or behavior change. Pair2 unchanged | Updated sync hash/time and recorded new backend-reported test count. No new screen/conflict/pending proposal; flow doc untouched. Real-provider success remains unverified |
| 2026-10-10 05:43 follow-up | Concurrent Pair1 B5.2 Connect built, read-only verification, rejected422 vs temporary503, metadata-only success;658 backend-reported tests but provider successes mocked | Included Connect contract/permission/error/lost-response states across Integrations, Providers, API/readiness. Pending45; no real-provider success claim; Pair2 deployment not inferred. Flow doc unchanged |
| 2026-10-10 05:45 | Pair2 B3.15 built; SectionC pushed (642 backend-reported tests). Phase2/4 latest build notes synced and code pulled; B5.1 report copied but code not present locally | Updated channel CRUD/test contract, no saved cap, safe URLs/retained secrets, test states, API/readiness/provenance. New live IP-added routing conflict; B2.7 layered2FA wording and Control Panel catalog difference remain clarification points. Pending44; flow doc unchanged |
| 2026-10-10 04:15 | B5.1 cloud-provider account list built Pair 1, permission-guarded organization metadata, filters/search/pagination; mutations still pending | Updated Integrations, Providers, API architecture, Phases and Missing backend; real list contract replaces missing endpoint and unsupported usage-count claims. A concurrent backend follow-up reports 557 tests and pagination links limited to approved filters; included in this sync. D-27 corrected to Bhavik's already-settled organization placement. Pending entry 43, flow doc untouched; no new conflict, usage count is an unpublished contract gap |
| 2026-10-10 03:59 | Pair 1 selectively copies Pair 2 Phase 3 rules/build statuses; corrects Phase 2 invitation/permission status; records Phase 4 pushed to GitHub main (e9a4210, a43e3f6), with 517 tests/Pint/PHPStan/migrations/concurrency checks reported passed on 2026-10-09 | Updated source provenance, Auth/Account/Organization readiness notes and traceability. No new screen or rule: Account details were already covered from primary Pair 2. Pair 1 B3.14 is a doc report, not proof of deployment. Pending 30–42 already cover visible changes; no new pending entry, flow doc untouched. About-you, prohibited emails, invite Accept and NO TRIAL conflicts remain; do not reopen resolved readiness questions |
| 2026-10-09 17:44 | Pair 1 marks B4.7 built, including the formerly approval-pending deletion-safety extension. Ownership changes are respected by organization/account deletion; completed transfers survive former-owner account deletion. Pair 2 unchanged | Removed backend security-approval blocker across organization, API, audit and readiness pages. Added stale-delete/concurrent-account-deletion outcomes. Pending entry 42 refreshed, still unapproved; flow doc unchanged. Billing/recipient-plan guards and preview email delivery remain deferred/unverified; no new conflict |
| 2026-10-09 17:30 | Pair 1 B4.7 implemented; final security extension approval pending. Active/verified owner and recipient, independent confirmations, 48-hour requests, owner cancellation, unchanged defaults; transfer activity now recorded. Billing/recipient-plan checks deferred | Updated Organization & Members, Organizations, Audit log, API architecture, Phases and Missing backend. Real five-endpoint contract and challenge/error states; no claim of fully ready or enforced billing guards. Preview SMTP delivery flagged. Pending entry 42; flow doc unchanged. Pair 2 unchanged |
| 2026-10-09 16:55 | Pair 1 confirms B4.1–B4.5 and B4.8–B4.11 built; publishes detailed B4.8 activity contract. B4.7 transfer pending; B4.6 share and server-deletion guard wait for Phase 8. Pair 2 unchanged | Updated Audit log, Organization & Members, Members, Roles, Permissions, Phases, Missing backend and API architecture. Replaced speculative audit fields/search/export with published type/action filters and actor snapshots; permission is activity-view, not fixed Owner/Admin-only. Pending entry 41; flow doc unchanged. No new decision conflict; prior invite/NO TRIAL conflicts remain |
| 2026-10-09 12:50 | Pair 2 built 3.14 In-app notifications, pushed Section B to GitHub, and confirmed that unverified users may use every account endpoint (Jayshree, following Pair 1). 3.14: the list shows unread by default with an all view for history, newest first, 10 per page; the unread count comes with the list and also has its own cheap endpoint the backend says to poll for the bell; mark one or all read, both replying with the new count; every row carries its own title, message (translated), icon, link and actor. Real notifications only start arriving with Phase 11. Migrated V7 notifications keep their English text | This is more data-driven than we had planned, and it deletes two mappings. Each row brings its own icon and its own link, so there is no event-to-icon or event-to-route table in the frontend — a future event we have never heard of still renders and still navigates. And actor names the teammate who acted, or is empty when it was the user, so "Ravi shared web-1 with you" versus "you shared web-1" comes from one field instead of a comparison we write. Polling is settled rather than assumed: this page used to say "poll the unread count (no broadcasting in Phase 1)" as our own choice; the backend has now published a cheap count endpoint and told us to poll it, so that is the design, with the full list fetched only when the bell is opened. Marking as read needs no refetch. Two honest things written down rather than discovered later: the list stays empty until Phase 11, so the empty state is the normal state for a while and must read as "nothing yet" rather than looking broken; and because old notifications keep their original English text, a user reading Central in another language will see a mixed-language list — intended, and recorded on FE: Notifications & mail so nobody "fixes" it. And one disagreement between the backend's own two documents, flagged rather than quietly resolved: the project doc now says unverified users can use all account endpoints, while the API reference still says a banned or unverified account gets 403 at the top of its Account sections. API architecture carries a [!CONFLICT]-style warning saying to follow the project doc — it is newer and matches Pair 1's 2.2 — and noting that anyone reading the reference alone would build a verification wall that does not exist. Status: only 3.15 channels and 3.17 server alerts are left in Phase 3; the bell is buildable now. Pending entry 40 |
| 2026-10-09 12:20 | Pair 2 built 3.12 Activity log, and that completes "Section B" — Phase 3 is built except notifications. Account activity only, newest first, 10 per page, filters for type and action; each row carries a ready translated sentence plus IP, browser and platform, and a flag for actions a ServerAvatar admin took on the user's behalf; login token only (the API token is refused); kept forever for now. The decision underneath (Jayshree): one shared activity log in Central with a scope — account for 3.12, organization for 4.8 | The shared log is the part that changes our plan, and it makes the work smaller. This site treated the account activity list and the organization Audit log as two separate screens; they are one log with a scope, recorded the same way by both pairs. So it is one table component used twice, and the shape published with 3.12 is the shape 4.8 will arrive with. Written as a [!NOTE] at the top of the audit page. Two details save real work. Each row already contains a finished, translated sentence, so there is no event-key-to-English mapping for us to write or keep in the dictionary. And the filter options come back with the response, listing only the types and actions the user actually has entries for — so the dropdowns are built from the data, never hardcoded, and a new backend event appears in the filter by itself. One row genuinely needs design: an entry can be marked done by a ServerAvatar admin, and that has to be visible at a glance — it is the difference between "I did this" and "someone from support did this to my account". On the organization log the same field becomes who acted, which is the point of an audit trail. And one thing deliberately not written down: retention. "Kept forever for now" is not a promise to print on a screen. Status updated honestly across the site: Missing backend's Account row goes to P3 — the whole account page is buildable, only Notifications waits — with Phases, the account page header and API architecture matching. One restraint: Pair 2's change log says it pulled Pair 1's 4.2–4.5, but Pair 1's doc only declares 4.1, 4.2 and 4.3 built, so this spec does not mark 4.4 or 4.5 built on a pull note alone. Pending entry 39 |
| 2026-10-09 11:50 | Pair 1 built 4.2 Delete organization. Owner only — an Admin gets 403; the owner types the organization's name to confirm; refused while it is the owner's default (organization_is_default), which is how "the last one stays" is enforced, as V7; roles, memberships, pending invitations and the logo go with it; other members' defaults move on their own; and the servers check (organization_has_servers, 422) arrives with Phase 8. Pair 2's doc unchanged | Our screen was right in shape, and three details sharpen it. The typed name is now a backend requirement, so type-to-confirm stops being our own nicety and becomes the contract — exact match. An Admin can reach the screen but cannot use it, so the action should be hidden or disabled rather than failing on click (new Edge cases row 31l). And the dialog should list what disappears — roles, memberships and pending invitations — instead of only asking for the name, because an owner deleting an organization will not otherwise realise the outstanding invites go too. The detail with the widest reach is about other people: a member who had this organization as their default is moved to another one by the backend. So someone who changed nothing can open Central and find the switcher pointing somewhere else — exactly the way people end up acting in the wrong organization. Row 31k says to tell them once, by name, rather than switching silently. One honest limit recorded rather than assumed: the servers refusal is not live yet — it lands in Phase 8 — so for now the only refusal that fires is the default one, and our screen must not promise otherwise. Both FE: Organizations and Organizations updated. Bhavik's rule holds unchanged: the default organization can never be deleted, so delete only ever applies to extra organizations. Nothing for the flow doc beyond entry 38 |
| 2026-10-09 11:40 | Both docs, and the Pair 1 half answers this morning's open question. Pair 1 rewrote 2.2 / 2.3 / 2.11 to the V7 flow (Vishal): an unverified user can log in, refresh and use the panel; email_verified comes back on login, register and the current user; and only four actions need a verified address — sending or resending an invitation, ownership transfer (4.7), creating a server (8.8) and promo credits (Phase 7). The old "account stays inactive until verified" is gone. Pair 2 built 3.13 API access — on / off and new token, no password, the token never expires and is shown at any time (Jayshree); V7 tokens migrated; survives a password change or reset; can only view the profile, everything else answers 403 api_token_not_allowed | The first thing to do here is fix my own note from 50 minutes ago. The 2.1 warning on FE: Auth screens said "every protected call answers email_not_verified until the email is confirmed". That was wrong, and the truth is better: the panel is open and only four named actions are guarded — now written as a small table of exactly which, with the rule that the banner should read email_verified rather than provoking a 403 to find out. Edge cases row 2 is corrected the same way (login no longer fails) with a new row 2z for the four guarded actions. And it answers D-57 outright, the day it was raised: the plan page is not guarded, so a brand-new user really can pick a plan before verifying — Bhavik's rule works as intended, and the banner is a reminder, not a gate. D-26's first difference is now completely closed, in two steps today: tokens at sign-up, then the whole V7 flow. On 3.13, our row was half wrong twice over, so it is replaced rather than patched: it said "users do not create new ones" (there is a new-token action) and planned to show the token masked (it is returned in full, any time). The feature stays excluded from the frontend by Bhavik's rule — the row exists only for traceability — but two of its facts matter elsewhere: the token is not a session, so "log out other devices" and "change password + log out all devices" leave it working, which is exactly the copy trap flagged on 3.16; and api_token_not_allowed is a real published code. One older claim of ours is also corrected: Architecture and FE: Foundation said the personal token "gets its own expiry when created" — that was inferred from Phase 1 leaving Sanctum's global expiry empty. It never expires. Pending entry 37 |
| 2026-10-09 11:20 | Pair 1 built 4.3 Invite members and 2.6 Invitation password. Three rules with it: designation is required (as V7); links last 7 days with resend / cancel; and signing up with a valid invite token for the same address joins the organization automatically — by email or Google / GitHub (Vishal) — with that account arriving verified. Pair 2's doc unchanged | The auto-join is the part worth reading twice, because it creates the shortest path in the product: open the invite → sign up → already signed in, already verified, already a member. No check-inbox step, no verification banner, no Accept click. Written as a [!NOTE] on FE: Auth screens with two precisions, because the wording could easily be over-read. First, it is the sign-up path only — an existing user still has to accept, which is exactly what Bhavik's rule was protecting: nobody is silently added to an organization. Second, the backend doc now holds both sentences at once — "every invite must be accepted, including by existing users" and the auto-join — so the sensible reading is that signing up through the invite is the acceptance, and that is how this spec records it rather than declaring a contradiction. It also narrows D-57, this morning's open question about unverified users: the problem only ever applied to people who sign up on their own, since invited users never meet the unverified state. Two smaller but real corrections. Designation is required, and this site showed it as a plain field — an invite cannot be sent without it, so it is now marked required here and on Members. And a pending invite can now vanish because the person signed up, not because anyone clicked Accept, so the members list should refresh on its own instead of waiting for an acceptance event. 2.6 is no longer a blocker: the auth page said "the invite screens stay unbuildable for now" — that is gone, and Missing backend drops Authentication to P2 with only the permission middleware left waiting on Phase 4 roles. Pending entry 36 |
| 2026-10-09 11:05 | Pair 2 built 3.10 IP whitelist — switch with no password; on adds the current IP, off removes every IP; the list shows approved and pending addresses (pending = a login from that address is waiting for its emailed link, 2.8), with the current IP and the on/off state alongside; adding works only while it is on and approves a pending address; max 100; removing one says whether it was the address you are on. Security email on every change. They also pulled Pair 1's organizations, so the profile now returns real ones | Two rules here are more dangerous than they look, and both are now written on the screen rather than left to discovery. Off is not a pause — it empties the list, and turning it back on restores nothing, so the switch needs a confirmation that says the addresses will be deleted. And removing the address you are using is allowed: this session survives, but the next login from it needs an emailed approval — the backend reports exactly that, so the screen should say it instead of blocking the action, which is what this page previously guessed (Assumption is gone). The pending rows are the genuinely new idea: the whitelist page is now also where a user sees that a sign-in is waiting for approval, and since adding a pending address approves it, a pending row can carry an Approve action instead of sending them to hunt for the email. Noted on 2.8 in FE: Auth screens too. The 100 cap and "already whitelisted" both have published messages, so we show theirs. Three edge cases added (31h off wipes the list, 31i removing your own address, 31j the cap). And one note of ours is corrected after an hour: this morning the profile's organizations came back empty, and this site said to design an empty state for it. It is real now — the organizations the user belongs to, sorted by name, each with logo, an owner flag, a default flag and the user's role. That is more useful than it sounds: the switcher, the "Default" marker and a role badge need no call of their own (recorded on FE: Organizations), and 3.7's warning becomes concrete — the delete-account dialog can now say how many organizations the user owns rather than warning vaguely. Four paths added to API architecture. Pending entry 35 |
| 2026-10-09 10:50 | Pair 1 only, one sentence, and it changes the first screen of the product: sign-up now returns tokens like login (2.1, Vishal) — access token, refresh token, user and organizations — while protected endpoints keep answering email_not_verified until the address is confirmed. Pair 2's doc unchanged | This reverses what FE: Auth screens said and closes a long-standing disagreement in our favour. The 2.1 states line read "no auto-login after registering (inactive until verified)"; now Create account lands the user in the app, signed in. Written as a [!WARNING] with a then/now table, because the consequence is bigger than the sentence: the check-inbox screen stops being a wall and becomes a message, and the unverified state has to be designed as a state of the app — a persistent banner with Resend, plus a clear refusal wherever an action is blocked — rather than a screen standing in front of it. D-26 is now three-quarters resolved, which is worth recording properly: this was difference (1) of four — Bhavik asked for V7's "logged in right away, only some actions blocked" and the backend had "inactive until verified". The backend has come to V7. Difference (2), the about-you step, went the same way earlier today for sign-up (the profile half stays flagged), and (3) invite-accept was settled the backend's way with Bhavik's agreement. Only the forgot-password wording is left. Updated on Open questions, Authentication and the auth page's own D-26 note. And it raises a real question rather than answering everything — D-57. Bhavik's rule is that a new user picks a plan immediately at /billing/plan; if every protected call is refused until verification, that step cannot run before the inbox is checked, and the true first screen is verify your email. If plans are exempt, it works as intended. Both are defensible, only one can be built, and it decides the shape of the first five minutes of every new account — so this spec does not guess. One restraint worth noting: the exact register path is not published (the API reference is Pair 2's endpoints only, and auth is Pair 1's), so API architecture records the /api/v1/auth/* group and the response, and invents no path. Pending entry 34 |
| 2026-10-09 10:40 | Both docs. Pair 2 built 3.8 + 3.9 — the whole 2FA block. Email 2FA goes on without a password and off with one; six backup codes (XXXX-XXXX) are created with the switch and shown once, after which only counts come back; new codes need the password and kill the old ones; turning 2FA off removes the authenticator and every code. The authenticator needs email 2FA on first, returns a secret + otpauth:// link valid 10 minutes, turns on only after one correct code, and falls back to email codes when switched off. Migrated V7 users cannot see their old codes and must create new ones (Jayshree). Pair 1 published a 3.7 rule (Vishal) — deleting an account deletes every organization the user owns, and its members lose access — and their change log says 4.1 Organizations is built | This corrects a mistake of ours that would have produced the wrong screen. This page described 3.8 and 3.9 as a choice — pick your method, with the authenticator turning email off. It is a ladder: 2FA on (email) first, the authenticator on top, and removing the authenticator drops back to email rather than leaving the account bare. One section with a second step, not two competing switches. "View backup codes" is gone too — the codes cannot be read back at all, so the only honest screen is a count plus Create new codes, which makes the once-only dialog the user's single chance: copy and download, and an acknowledgement before it closes. The available / used counts are worth using as a warning, since someone down to one code is one lost phone from a lockout. One real dependency arrives with this: the backend sends an otpauth:// link and no image, so the frontend must draw the QR itself — Phase 3's first new library — with the secret always shown as text for a camera that will not cooperate. And a migration message we have to write ourselves: a V7 user sees codes they can never read, so the screen must say so and offer new ones. Three edge cases added on Edge cases — expired setup (31e), last code used (31f), and 2FA off taking the authenticator and codes with it (31g). On Pair 1's side, the organizations rule belongs in the delete dialog, because it is the only consequence of deleting an account that harms other people: it should name how many organizations will go and that their members lose access. Recorded on 3.7 and on FE: Organizations, where 4.1 is marked built — noting that their own Phase 4 status line still says "not built yet", so this follows their change log. Seven paths added to API architecture. Pending entry 33 |
| 2026-10-09 10:20 | 3.16 Active sessions built — this device listed first, then newest sign-in; log out one device (this one included) or all other devices, which sends a "logged out of your other devices" email (11.23) and reports how many went; API tokens are not sessions and survive; refreshing a token keeps the same row. The API reference grew with it, and login history now sends browser and platform already worked out | One of our own notes was wrong, so that is the first fix. 3.16 said "the current row can't be revoked from the list". It can — so every row has a Log out action, and the one on this device ends as a sign-out. The backend returns the same logged_out flag it uses for the password form, so the screen clears the tokens and goes to login instead of refreshing a list it can no longer read. Second correction, an hour old and mine: when 3.11 landed the reference sent only the raw user-agent, and this site said parse it into "Chrome on Windows". It now sends browser and platform ready to show (Unknown when it cannot tell), so no parser should be built — corrected on FE: Account screens rather than quietly swapped. Two honest edges are now specced on Edge cases: a session that already signed out answers not found, which should refresh the list and say "already signed out" rather than raise an error (31c); and sessions older than today come back with an unknown browser and no IP, method or sign-in time, so the table has to live with blank cells instead of four "Unknown"s in a row (31d). One copy trap worth stating once: "all other devices" must not imply the personal API token dies with them — it does not. And the standing conflict hardened again: Bhavik's 2026-10-07 rule names four emails not to add, and two of them are now built behaviour — account deleted (3.7) and logged out of all devices (3.16). FE: Notifications & mail says so plainly; it is a decision to take, not a flag to keep. Four real paths added to API architecture. Pending entry 32 |
| 2026-10-09 10:05 | The backend published an API reference for the frontend (Pair 2 endpoints only, re-renders every 30 s) and built 3.11 Login history — newest first, 10 per page, successful logins, plus a login-method column (password / google / github) that V7 did not have | The API reference is the bigger of the two by far, and it changes how this site should be used. Every field list here came from the project doc's one-line descriptions, so our rules were careful guesses; the reference gives exact names, limits, response shapes, messages and status codes. Recorded on API architecture with its URL, what it covers (the account profile half and login history — not authentication, which is Pair 1's), and the published shapes: {data} / {data, message}, {message, code} for 401/403, {message, errors} for 422, delete_protection_enabled for 423, and Laravel's paginator for lists. The eight real account paths replace the single guessed V7 row in the dependency table, and the unbuilt security half now sits in its own row marked Missing so nobody mistakes it for ready. Two working rules came out of it: show the backend's own message (already written and translated) instead of adding a second English string that will drift, and treat the much tighter limits on sensitive forms — 5 a minute for password and delete, 3 per 10 minutes for an email-change request — as a real waiting state, since the 429 message carries the seconds. And it asks for a page we did not have: /confirm-email-change?token=…, taking the token in the query string and working signed out, because the link may be opened on another device. Added to Routes with two new Edge cases rows (31a tight limits, 31b the link opened elsewhere). Three smaller confirmations on FE: Account screens: the avatar is a Gravatar, so there is no upload to design and the picture changes with the email; pending_email is a real field, exactly the state we had assumed; and organizations returns empty until the Organizations phase lands, so 3.1 needs an empty state today. On 3.11 itself, the method column is the one piece of new design — it lets someone scanning for a sign-in they do not recognise tell a password login from Google or GitHub — and the browser string arrives raw, so parse it for the table and keep the full text on hover. Pending entry 31 |
| 2026-10-09 09:48 | A one-line status change: Phase 3's built items 3.1–3.7 are now "Section A, pushed to GitHub 2026-10-09". No rule, screen, field or message changed, and Pair 1's doc did not move | Nothing new to specify — but it made one of our own pages wrong, which is why this is not a no-op. Overview still said the backend had only Phase 1 and that there was "not a usable session yet: login and the refresh token are backend Phase 2". That has been untrue since this morning, and the push is the moment it is worth fixing: three phases are now on GitHub — Foundation, Authentication and Phase 3's profile half — so the frontend has a real server with a working session, and the account page's profile tabs can be built against live endpoints. The honest counterpart is written next to it: the nearest real gaps are the security half of Phase 3 (2FA, IP whitelist, active sessions, login history), the notification channels, and anything needing permissions or invitations, which both wait on Phase 4. Missing backend's Account row moves from "requirements complete" to built, P1 → P2, naming exactly which items landed and which did not — the useful distinction being that the account page can be built now while its Security tab cannot. FE: Account screens says the same in its header. Nothing for the flow doc beyond a build line — pending entry 30 covers 3.7 itself, and its build line is refreshed with the push |
| 2026-10-09 09:35 | Pair 2 built 3.7 Delete account — password + an optional reason (as V7); refused while delete protection is on (Jayshree, same day); the negative-balance check arrives in Phase 6 and the servers check with the Servers phase; the user is removed, the email becomes free to sign up with again, a deleted-users record is kept for admins (as V7, 17.6), they are logged out everywhere, and an "account deleted" email is sent (11.23). Phase 3 is now built end to end: 3.1–3.7. Pair 1's only change was a rename of backend internals (OrganizationPermissionSeeder, permissions:sync-organization) | This row closes a guess and opens a shape. The dialog had carried a type-"DELETE" confirmation marked Assumption; the real rule is password + an optional reason, which also matches Bhavik's settled decision, so the guess is dropped rather than kept alongside. The more useful part is that there are three refusals and only one exists today — delete protection now, negative balance from Phase 6, servers from the Servers phase. So the screen wants one general "here is why we refused, here is where to fix it" shape, not three hard-coded branches; the one to get right today is delete protection, linked straight to the switch, since the user may have set it weeks ago. Two facts are worth not hiding from the user: the email can be used to sign up again, so nothing should imply the address is burned, and a record is kept for admins — so a dialog promising total erasure would be wrong. One flag, not a new one: the "account deleted" email is already inside Bhavik's 2026-10-07 conflict (email is primary, no new extra emails — it names "account deleted" by name). FE: Notifications & mail now records that this conflict has hardened, because the email is attached to built code rather than a plan. Pending entry 30 |
| 2026-10-09 09:13 | Both docs. Pair 2 built 3.5 + 3.6 — email preferences (three switches, all on by default, and required security emails (11.19) ignore them) and delete protection (on / off, no password, off by default, and every delete route now answers 423 "turn off delete protection first" — V7 only checked this in the frontend). Phase 3 built: 3.1–3.6. Pair 1 built 4.9 + 4.11 (37 organization permissions in a seeder, with a sync command — renamed mid-morning to permissions:sync-organization, which is a backend internal and only noted so the name here is not stale) — and reversed yesterday's rule about the Control Panel: 12.3 now has its own permission list, table and seeder, as V7's separate hosting-user seeder, built in Phase 12 | The reversal is the part that corrects this site. For one day 4.11 read "the same permissions are used for Control Panel users", and this spec recorded it as the answer to a question FE: Control Panel & White label had marked unpublished. It is not: 12.3's tick-list is a second catalog, so that question is open again and the entries are unknown. Both pages are corrected rather than quietly rewritten. The shape underneath is more useful than the single fact: there are now three separate permission catalogs — organization (4.9), admin (17.2) and Control Panel (12.3) — each with its own table and seeder, sharing only the sync mechanics. So build the matrix once and point it at whichever catalog a screen needs; never assume the entries match. On the Phase 3 side, 3.6 is the one with reach. V7 treated delete protection as a UI courtesy; V8 enforces it server-side, so any delete can come back 423 wherever it is triggered — including places where no guard was written. Two rules follow: handle 423 on every destructive action, and make the message point at the switch with a link, since a user who has forgotten the setting has no other way to find it. Edge cases row 35 is corrected from a guessed 403 to 423, and Responsibilities now says the enforcement is the backend's. 3.5's defaults are recorded too — all three on, with security emails ignoring them, which matches 11.19's locked rows. Pending entry 29 |
| 2026-10-09 08:28 | Pair 2 built 3.3 Change email, with the detail filled in (Jayshree, as V7): confirm link to the new address valid 24 h; the email changes only after confirming; a new request replaces the old one; and afterwards an "email changed" notice goes to both addresses — the old one showing the new address partly hidden. Phase 3 built so far: 3.1, 3.2, 3.3, 3.4. Pair 1's doc unchanged | The pending state this page had marked <span class="badge b-assume">Assumption</span> is confirmed — and two details sharpen it. Because the address changes only after confirmation, the profile must keep showing the old email with a pending marker and never optimistically show the new one, or the user cannot tell whether it worked. And because a new request replaces the old, re-requesting is the fix for a typo — so the marker should show the latest address asked for, and the screen can say plainly that asking again cancels the previous link. The 24 h validity is now stated alongside the other link lifetimes. The two notices are not our screen, and the partly-hidden address in the old mailbox is a deliberate touch worth not undoing: nothing should display the full new address where the old owner could still see it. Written on FE: Account screens. Pending entry 28 — the pending state and the re-request behaviour are user-visible; the email contents are not |
| 2026-10-09 07:58 | Pair 2 built 3.4 Change password — and rewrote the rule while doing it. It was "current password required, logs out other devices". It is now as V7: an optional "Log out all devices" checkbox where ticked logs out every device including the current one, and not ticked logs out nobody. The "password changed" security email (11.19) goes out either way. Phase 3 built so far: 3.1, 3.2, 3.4. Pair 1's doc unchanged | This page's 3.4 row was wrong in both directions — it said other devices are signed out automatically and that this device stays. Neither holds, so the row is rewritten rather than amended. The useful consequence is that one form now has two different endings: ticked → the user is signed out and must land on login; not ticked → they stay where they are and no session anywhere is touched, so the success message must not claim otherwise. A line beside the checkbox saying it signs out this device too avoids a genuinely unpleasant surprise. And a trap worth naming before anyone writes the copy: the product now has two password paths with opposite session behaviour — reset (2.5) still logs out all devices unconditionally, while change (3.4) logs out nobody by default. The asymmetry is sensible — a reset implies possible compromise, a voluntary change does not — but reusing the reset flow's "All devices were signed out" message on the change form would be wrong in the common case, and reusing its redirect-to-login would sign someone out for no reason. Written as a [!NOTE] on FE: Account screens. Pending entry 27 |
| 2026-10-09 07:43 | Pair 2 started building Phase 3 — Account, feature by feature: 3.1 View profile and 3.2 Update profile are built. And 3.2 gained its field list: details are mobile, country, region, timezone (the V7 fields), while the onboarding answers — company size, industry, management experience, heard about us — stay in the same endpoint as free text, imported as-is from V7 (Jayshree). Pair 1's doc is unchanged | This reopens something this spec closed six hours ago, and the correction is the main point. When 2.1 dropped the onboarding questions from sign-up, FE: Auth screens recorded the conflict with Bhavik's "no About you questions" rule as closed. That was true for sign-up and over-generalised: his rule covers Account information too, and 3.2 still carries the four fields there. So the conflict closed for one screen and is still open on the other — flagged with a > [!CONFLICT] on FE: Account screens, and the auth row is corrected rather than left reading as settled. The frontend follows Bhavik and does not render them. What makes this sharper than a normal disagreement is that the data is migrated: V7 answers arrive as-is, so the values will exist on real accounts with no screen that shows or edits them. Defensible — they are legacy marketing answers, not account settings — but it should be a decision rather than an accident. The useful half of 3.2 is the field list, which this spec only had as "details": mobile, country, region, timezone, with country and region as selects and timezone carrying more weight than it looks, since every date on every screen is formatted from it. Also removed the stale onboarding answers mention from the Account page's own layer diagram. Pending entry 26 |
| 2026-10-09 06:58 | Phase 2 — Authentication is built (Pair 1, main) — the second phase to exist, and the one this spec leans on most. Endpoints under /api/v1/auth/*; login answers in two shapes — two_factor_required: false + tokens + user + organizations, or true + a challenge_token; stable error codes published (email_not_verified, account_banned, ip_not_approved, two_factor_expired, session_expired, unauthenticated); 2.9 records the built token method — a Sanctum access token plus Central's own refresh token, hashed, never usable as a Bearer, rotated on every refresh, and reusing a spent one revokes the whole login chain; 2.11 adds rate limits on every auth endpoint with a translated 429 and an auth.active group (banned → refused and logged out everywhere; unverified → refused). Not built: 2.6 invitation password and the permission middleware, both waiting on Phase 4 | The backend also named the frontend pages it expects, and four of ours were wrong. These are the targets of links inside emails, so a mismatch means every verification, reset and IP-approval link 404s: /verify/:token → /verify-email/{id}/{hash} (two parameters, a signed-URL shape); /reset-password/:token → /reset-password (no path parameter — the token comes in the query); /ip-approval/:key → /approve-ip; /oauth/:provider/callback → /auth/social/{provider}/callback. All four corrected on FE: Auth screens and Routes. Two error codes were guesses and are now right: unverified → email_not_verified, banned → account_banned on Edge cases — with the rule on API architecture to map by code, never by message text. D-1 is answered in substance: tokens come back in the body, exactly what the BFF asked for, and the 2FA step is driven by a challenge_token rather than a half-made session — cleaner than this spec assumed, since nothing is signed in until 2FA passes. The sharpest constraint Phase 2 puts on us is the refresh rule: rotation plus reuse-revocation means a retried refresh, or two concurrent requests both refreshing, logs the user out of everything, so refresh must be serialised through a single in-flight promise and never auto-retried. One detail still missing: no expires_in-style field is named Open question, so nothing should hard-code 15 days. Missing backend drops the auth row from P0 to P1 — entry works, invitations and permissions do not — and no me endpoint appears in the built list. Pending entry 25 for the four route paths |
| 2026-10-09 06:43 | Pair 1 only — 2.4 Google / GitHub login gained three rules (Vishal): linking or creating needs a provider-verified email; new social users are marked verified at once, with no activation email (unlike V7); and an unverified account becomes verified on social login. Pair 2's doc is unchanged | The pattern across today is the finding worth reporting, not the single item. Email verification now has three exits: the verify link (2.2), a password reset (2.5, added this morning) and a social login (2.4, added now). So nothing may treat the verify link as the only way out — the practical rule, written on FE: Auth screens and as a new 2a row on Edge cases, is to read the verified flag from the API after every login and on session restore, never infer it from how the account was created and never cache it for the session. A banner that outlives the state it describes is exactly the bug three routes invite. Two smaller consequences. The social path never touches the verification screens — no check-inbox step, no banner — which means the email path and the social path end in different account states, so a shared "after sign-up" screen would be wrong for one of them. And there is a new failure state with no message yet Open question: if the provider hands back an address it has not verified, the sign-in stops. It belongs in the /login?error=<code> list, and the message needs to be actionable — naming the cause and the fix, since a generic "sign-in failed" leaves the user nothing to do. Code and wording are still the backend's to give; nothing invented. Recorded as 2b on Edge cases and on Authentication. Pending entry 24 |
| 2026-10-09 06:28 | Pair 1 only — 2.8 IP whitelist at login gained three details (Vishal): exact IP matching, as V7 (no ranges; ranges only ever as manual entries on the whitelist page, and the doc says "if ever"), a new approval email at most once every 5 minutes per IP, and after approving, the user logs in again. Pair 2's doc is unchanged | One of the three confirms this site rather than correcting it — FE: Auth screens already said "approve it, then log in again", so nothing changes there. Worth keeping explicit anyway, because the tempting design is to resume the half-finished login from the approval page, and approval only allows the IP. The five-minute limit kills a button: a resend on the blocked screen would lie — inside five minutes no new email is sent while the screen still claims one was. So either no resend at all, or a resend with a visible cooldown; never one that appears to work and does nothing. And exact matching is the one with a real user cost. It means a dynamic home IP or a mobile connection is blocked again every time the address changes, each time needing a fresh email and a second login, with no way to pre-approve a range. The honest place for that warning is not the login screen but the switch itself, so it is written on 3.10 in FE: Account screens — say it before the feature is turned on rather than letting the user discover it — and the IP field takes single addresses only. Also on Authentication and a new 3b row on Edge cases. Pending entry 23 for the resend affordance and the warning placement |
| 2026-10-09 06:13 | Pair 1 only — 2.7 2FA at login gained the detail that was missing (Vishal): one method per user — email code or Google Authenticator, never both (as V7) — plus one-time backup codes stored hashed; Authenticator codes tolerate ±30 s clock drift and cannot be reused. Pair 2's doc is unchanged | "One method per user" corrects this site's own screen, and it is not a small correction. FE: Auth screens listed three methods with "method switch links under the input", which implied the user chooses between email and Authenticator at login. They cannot: the account has one, so the screen shows that input and offers exactly one alternative — "Use a backup code instead". One input, one fallback link, not a chooser. The same correction lands on the Account side: 3.8 and 3.9 read as two independent switches, so a user could appear to enable both and then wonder which one applies. They are a choice — turning on Authenticator turns the email method off — and FE: Account screens now says so. One rule is a real failure mode worth designing against: a code cannot be reused, so a user who submits, hits a network hiccup and resubmits the same code is refused while it is still on their screen. Never auto-retry a 2FA submit — the API-client rule against retrying non-GET calls already covers it, and this is the case that makes it matter — and disable the button on submit so a double-click cannot spend the code. And one rule is deliberately not surfaced: the ±30 s drift tolerance is recorded only so nobody builds a "check your device clock" hint for a problem the backend already absorbs. Hashed backup codes confirm 11.21 — shown once, never retrievable. Also on Authentication and Security. Pending entry 22 — the login flow's 2FA step and the Security tab both change shape |
| 2026-10-09 05:58 | Pair 1 only — two rules added to 2.5 Forgot / reset password (Vishal), both of them user-visible. (1) A successful reset now also marks the email as verified. (2) A banned account cannot reset: no email is sent, and a link that was already valid is refused. Pair 2's doc is unchanged | The first one is quietly useful: a reset becomes a second route out of the unverified state, which matters for anyone whose verification email never arrived. The screen work is small but real — after resetting and logging in there must be no "please verify your email" banner — and the thing not to do is advertise it, because "reset your password to verify your address" is bad advice to put in front of users. The second one needs two messages the backend has not written Open question. On /forgot-password nothing is sent, so the generic "if an account exists, we sent a link" leaves a banned user waiting for an email that never comes. On /reset-password/:token an existing link now fails, so it needs an error that is not "expired" — it has not timed out, it has been refused. And there is a genuine decision underneath: login already shows a separate banned message (2.3), so the product does disclose banned state after a correct password — but the forgot form has no password to check, so naming "banned" there would reveal account state to anyone who types an email. This spec keeps the generic message on the forgot form and a distinct "this link can no longer be used" on the reset screen, which leaks nothing, and says plainly that the backend may overrule it. Written on FE: Auth screens, Authentication and Edge cases as a new row 3a. Pending entry 21 — no new screen, but the flow doc does carry ✔/✖ paths with their messages, so these are two lines in the forgot/reset flow plus one note about the banner. Offered rather than assumed |
| 2026-10-09 05:28 | Three things, and the biggest is Bhavik's not the backend's. (1) Bhavik removed the trial from V8 (2026-10-09): no trial, no banners, and a new user picks a plan right after sign-up at /billing/plan — with "No plans are available yet. Please ask the admin to create a plan." if the admin has made none. The backend doc still specifies a trial (7.6, plus trial rules in 7.1, 6.9, 6.13 and 17.19), and his instruction is to report those as conflicts only. (2) Pair 1 removed the onboarding questions from sign-up (2.1, Vishal) — "no onboarding questions at sign-up". (3) Phase 2 — Authentication is now being built by Pair 1 (2.1 Register started); Pair 2 waits for their push. Pair 1's database rename also propagated into Pair 2's copy | The no-trial rule touches eleven pages, and it reverses one of his own earlier decisions — until yesterday the settled rule was "trial starts automatically, plans picked later", recorded here as an intentional difference from V7. It is now the opposite, so the reversal is written down rather than quietly swapped. A > [!CONFLICT] on FE: Plans & subscription sets the two positions side by side and the frontend follows Bhavik. What comes out is more than a banner: the days-left display, the trial-end gate, the trial and trial_ended subscription states on Subscriptions, the sidebar's "trial" badge, the trial row on Plans, and the trial references on FE: Add a server, FE: Billing screens, End-to-end flows, User journey and Testing. What goes in is one screen: /billing/plan as 7.6a, specced with the detail that matters — a required step whose empty state is the admin's fault, not an error, so a user facing it can do nothing and the copy must say who to ask. Added to Routes. D-33 is moot — there is no "after a trial" — though its real question survives in a smaller form: nothing says whether Free is selectable at sign-up. D-56 raised for the unresolved half: 7.1 and 17.19 are admin settings, so an admin may still be shown a per-plan trial switch and a global trial mode that can never affect anybody — dormant controls are worse than absent ones. And one conflict closes: the backend dropping the onboarding questions means Bhavik's "no About you questions" rule and the backend doc finally agree — recorded on Authentication and FE: Auth screens |
| 2026-10-09 03:58 | Cosmetic for us: Pair 1 renamed its own database. Their copy now uses sv_central_backend instead of sv_central, because sv_central already holds the Central WordPress site — so the API needed a name of its own. Recorded in their 1.1 note and the setup-after-pull block; nothing else changed, and Pair 2's doc is untouched | No frontend impact at all — this frontend talks to sa-central-api-2, whose database is sv_central_2, and Pair 1's name never reaches us. Fixed for accuracy only: Architecture listed the pair databases as sv_central / sv_central_2 and now names the right one, with the reason — worth keeping, because a name that looks wrong tends to get "corrected" back by whoever reads it next. The Source documents table is updated to match. No open question, no conflict, no pending entry: a backend copy's own .env value is as internal as it gets |
| 2026-10-09 03:43 | Convergence only — Pair 1 caught up with Pair 2 overnight, and there is no new rule in it. Pair 1 took the whole of Pair 2's Phase 1: the Built status and its build notes, the setup-after-pull block, 1.10 Translations and 1.11 Code quality, the "decided by the frontend pair" wording on the login flow, the "not final" doc disclaimer, the stage change to development has started, and the removal of Q7 and Q8 from the open-questions list. A section-by-section check confirms Working method and Open questions are now byte-identical, and Phase 1 differs only where it should — each doc names its own database (sv_central / sv_central_2) — plus one cosmetic author label | Nothing to change on this site: every item above was read from Pair 2 and written up yesterday. Recorded here so the traceability is honest rather than silent, and the Source documents table now says the two docs agree everywhere. One thing worth passing on, though — a contradiction inside both docs. Their top line still reads "Status: Requirements gathering. Nothing has been built yet." while their own §4 says development has started and Phase 1 is built. It is the same staleness this site had yesterday in its Overview block, and in the same place: a framing line no phase number points at, so nothing prompts anyone to update it. Not editable from here — flagged for the backend team. No open question, no conflict, no pending entry |
| 2026-10-08 12:51 | Phase 1 is now pushed to GitHub main — it had been built-but-unpushed for about half an hour, and the three pages that said "not pushed yet" are corrected. And the project's own stage line changed, which is the part worth noticing. R4's "both pairs only prepare phases and the doc — nothing is built by either pair yet" became "development has started, feature by feature on main", with Phase 1 built by Pair 2 and Pair 1 taking it with a pull. The rest is backend setup: a new "Setup after pull" block (each copy sets its own .env — database, Redis DB numbers and prefix, HORIZON_PREFIX which must differ or the two copies process each other's jobs, CORS frontend URL, dashboard login — and points Supervisor at php artisan horizon), plus two build notes: strict Eloquent models outside production for N+1 detection, and Sanctum token abilities switched on later, "with the first feature that needs limited tokens" | This made one of our own pages wrong, so that is the main fix. Overview carried a [!DANGER] block saying the frontend and backend were both "the empty initial scaffold" and that "coding starts only after this spec is approved". Half of that is no longer true: the backend is building, the frontend is not. The block is now a two-row table saying exactly which half is where, with the honest conclusion — read this site as a specification, not a description of what exists — and the useful consequence: the frontend has a real server to build against, but not a usable session, since login and refresh are Phase 2. The site's status line and footer are reworded to match, and the R4 row above records the change. Two smaller notes on FE: Foundation: token abilities are not switched on yet, so a login token is unscoped and nothing of ours should send or expect ability names; and each backend copy sets its own CORS frontend URL, which with the BFF only bites on a direct browser call — worth knowing as a diagnosis, not a task. Nothing for the flow doc: the stage change is already covered by pending entry 19, and the setup block is ops detail |
| 2026-10-08 12:36 | One line changed, in the Phase 1 build notes. How /horizon and /telescope are protected: no longer an IP allowlist (OPS_ALLOWED_IPS) but a username and password set in .env, opened from the project URL, with separate dashboard domains planned later for staging and production. Nothing else moved | Cosmetic for the frontend — and a correction to this site, which carried the IP-allowlist wording for about twenty minutes. Fixed on FE: Foundation rather than left to rot, since it was published as fact. The standing rule does not change — those two dashboards are never linked from the frontend — but the new arrangement is a reason to be slightly stricter: they now sit on the same host as the API and are reachable from anywhere, so a stray link would surface an ops login prompt instead of nothing. No open question, no pending entry: how the backend guards its own ops dashboards is exactly the kind of internal the flow doc excludes |
| 2026-10-08 12:21 | Phase 1 is built — the first V8 code to exist. Pair 2 built it on main (not pushed yet; Pair 1 takes it with a pull), and the status line flips from "flow defined" to ✅ Built: MySQL sv_central_2 with its own user, Redis with its own DB numbers and prefix, Horizon with three queues under Supervisor, Sanctum Bearer tokens, Telescope local only, CORS, daily logs, trusted proxy, translations and Pint + PHPStan + Pest. Three build notes: API routes live in routes/v1/<domain>.php under /api/v1; the access token's 15-day expiry is set when the token is created (sanctum.access_token_expiration) with Sanctum's global expiration left empty so a personal API token (3.13) can live longer; and /horizon and /telescope sit behind an IP allowlist (OPS_ALLOWED_IPS) | One of these is a fact we did not have: the API is at /api/v1, and it is versioned. Recorded on API architecture with the rule that follows — keep the version in one place (the env base URL), never per call, and do not treat the version string as permanent. The token detail quietly helps D-1: an expiry that belongs to the token is one the login response can return, which is exactly what the BFF proposal asked for; leaving the global empty on purpose, so personal tokens can outlive a session, is the right call and worth not undoing. And the honest limit, which matters more than the milestone: there is still no login endpoint. Phase 2 carries authentication and the refresh token, so frontend Phase 0 can now be built against a real server but no session flow can be finished. Status flipped on Missing backend — the Foundation row leaves P0 after being the top blocker since this site began — plus FE: Foundation, Phases, Architecture and Dependencies. Pending entry 19 added: the flow doc tracks build readiness per module, and a backend phase landing is exactly what its Build lines are for |
| 2026-10-08 11:51 | Pair 2 closed the two oldest open questions on this site, with two new Phase 1 steps. 1.10 Translations (i18n) answers Q8, open since 2026-10-03: i18n is set up in Phase 1, every user-facing API text — errors, validation, emails, notifications — comes from lang/ keys, never hardcoded English, and a middleware reads Accept-Language and falls back to English. Which languages are offered is still "decided later". 1.11 Code quality answers Q7, reversing its "skipped for now": Pint + PHPStan (Larastan) are installed and Pint + PHPStan + Pest is a per-task gate. The backend's own question list is now down to Q3 alone (what Central shows when a panel is offline). Two smaller edits: the login flow moved from "decided later" to "decided by the frontend pair", and the doc gained a header disclaimer — "not final … details may change during development" | Q8's answer arrives by a different route than this spec proposed, and the difference is a real obligation. We asked for type + params so the frontend could translate; the backend translates server-side and returns finished text. That is simpler to consume — but a server-side fetch carries no browser headers, so the BFF must read the locale cookie and set Accept-Language on every call, including from server components. Miss it and every backend message silently falls back to English: a bug that ships quietly. Written on Internationalization, FE: Foundation and API architecture. What is left is not the mechanism but the list — the backend has not decided which languages it will translate, while this site specs eight. If it ships fewer, a user on an unsupported language gets our UI translated and the backend's messages in English, which is worse than consistent English — so the switcher should offer what both sides support. Still missing either way: a profile language field, so the choice lives only in a cookie. And D-1 became ours: "decided by the frontend pair" means the BFF proposal stops waiting for backend approval and is simply Bhavik's call. Missing backend drops the locale row from P1 to P2 — the mechanism exists, only the list is open. Pending entry 18 added for the language-list risk, which is the one user-visible part |
| 2026-10-08 11:36 | A second stack change, and this time both docs made it together: the database moves from MariaDB to MySQL. Step 1.1 is rewritten — driver mysql and never mariadb, target MySQL 8.4 LTS, utf8mb4 with collation utf8mb4_unicode_ci, strict mode, and a dedicated user scoped to one database. Development still runs on the server's existing MariaDB 10.11 — no separate instance — so the code has to stay MySQL-compatible: Eloquent and the query builder only, no MariaDB-only SQL (RETURNING, sequences, MariaDB JSON functions), json columns through Laravel casts, and UUIDs as char(36). The final check (1.9) now verifies the MySQL connection. Pair 2 also adopted everything from this morning — Sanctum, 17.2a, the V7 admin permission mapping and Phase 18's affiliate wording — so the two docs agree again | Almost none of this reaches the frontend, and it is worth saying so plainly rather than inflating it: we never touch the database. Two details do carry, and both are cheap to honour now and annoying to retrofit. First, UUIDs as char(36) mean an id can be a string — so API architecture now says treat every id as a string: no parseInt, no numeric sort, route params stay strings. That costs nothing where ids are integers. Second, utf8mb4_unicode_ci is case-insensitive, so a backend uniqueness check will treat MyApp and myapp as the same name Assumption — a "name already taken" error should not imply that changing the capitalisation will help. And since the charset is utf8mb4, names can contain emoji, so truncate by character and never by byte. Stack references corrected on Architecture, API architecture, FE: Foundation, Dependencies, Missing backend and Phases. One risk belongs to the backend, not us, but is worth naming: developing on MariaDB while targeting MySQL means an incompatibility would not show up in development. Nothing for the flow doc — database choice is exactly the kind of backend internal it excludes |
| 2026-10-08 10:18 | Auth changed from Laravel Passport to Laravel Sanctum (Vishal; Pair 1 only, Pair 2 unchanged) — the first architectural reversal since this spec began. 1.4 is rewritten: install:api, auth:sanctum, and Bearer API tokens only — explicitly no SPA cookie / stateful mode. Access token 15 days via expiration in config/sanctum.php; Sanctum has no refresh token, so Central builds the 30-day refresh itself in Phase 2 (2.9); token abilities replace Passport scopes; the personal API token (3.13) gets its own expiry when created, so V7's fixed 6 months is gone. CORS drops oauth/* (1.6), the final check uses an auth:sanctum route (1.9), and the refresh token plus sanctum:prune-expired move to Phase 2 | This is good news for D-1, which is the opposite of how a framework swap usually reads. The BFF proposal on FE: Foundation is unchanged — but Sanctum SPA cookies was its one real competitor, and the backend has now ruled that out itself. So the BFF is no longer a recommendation among options; it is what remains. D-1 narrows to two things: the response shape, and where Next.js keeps the tokens. The trap worth naming loudly, and now written on Authentication: the project rule says "cookie-based Sanctum session for SSR", and that is not Sanctum's SPA mode — there is no /sanctum/csrf-cookie call and no stateful-domain list. The cookie is Next.js's own httpOnly cookie carrying a Bearer token; the rule's real requirement (the browser never sees the token) is met that way. Reading it the other way would mean building an auth flow the backend does not serve. One sequencing consequence: with the refresh moved to Phase 2, no refresh endpoint exists until Phase 2 ships, so anything built against Phase 1 alone has a 15-day session and no renewal. And the refresh ask gets sharper: it is Central's own code, not a library feature, so the endpoint and its response are being designed right now — the moment to agree them. Rewritten across eleven pages: Authentication, FE: Foundation, FE: Auth screens, Architecture, API architecture, Security, Dependencies, Missing backend, Responsibilities, Findings, Open questions. Nothing for the flow doc — it carries no tokens or backend internals, and 2.9 / 3.13 are items Bhavik keeps out |
| 2026-10-08 09:18 | Pair 1 only, and small — but it sharpens the sharpest controls in the admin panel. New 17.2a: two admin actions are their own permission, manage only. Log in as user (17.10) is no longer covered by Users: manage — an admin can be allowed to edit users without being able to impersonate them; and Admin roles & permissions is its own permission, so only a role with manage on it can create, edit or assign roles. Also added: the V7 admin permission mapping — a V7 list / panel permission becomes view, a create / update / delete / status action becomes manage (user-list → Users view, user-status → Users manage, and the same for transactions, charges, promo codes, DNS, organizations, deleted servers), with user-account-login → Login as user and role-permissions → Admin roles & permissions. No admin loses access | 17.2a confirms an inference this page made an hour earlier and adds a shape nobody had: from the group list, FE: Admin panel had reasoned that an admin could see a user without being able to log in as them. That is now a rule — and because both new permissions are manage-only, the matrix has rows with one flag, where the organization catalog has rows with two or (five areas) view only. So the matrix must render three row shapes from the data, which is recorded on FE: Permissions & role matrix. One concrete design consequence: Log in as user should be absent rather than disabled for an admin without it — a greyed-out impersonate button is an invitation. The admin mapping is the more precise of the two migrations, and worth saying so: Phase 4's organization mapping had to widen access where V7 was finer and report the widened cases; V7's admin permissions were already action-shaped, so they split cleanly into view and manage with nothing widened. Two reports now need one home — the combined-role list and the organization widened-access list — noted together rather than separately. And the deleted-servers conflict hardened: deleted servers + restore now appears three times (17.11, the 17.2 group list, and this mapping), so it is clearly intended on the admin side and needs an answer rather than another flag. Also updated V7 migration. Pair 1 then took Phase 18 across at 09:19, mid-run — identical to Pair 2's, both codes count included, so no product rule changed and nothing on this site needed rewriting; the two docs now carry the same Phases 3–18. It also tightened Phase 17's affiliate note to "the user-side affiliate is kept — Phase 18, via Tolt", which is the same clarification this site made two hours ago, now in the backend's own words. Pending entry 17 extended; the flow doc was not touched |
| 2026-10-08 08:03 | Both docs sharpened the permission list, identically — and it grew past permissions into navigation. 4.11 now gives every entry its menu data: title, an icon as a Lucide name, a url, an order (decimals, so items slot in between) and a parent group — and states that the sidebar is built from the list: only what the role can view, sorted by order, icon drawn by name with a fallback. Plus: "changing an icon, link or order = edit the seeder and deploy." 4.9 / 4.11 also refine the storage — a role sets view and / or manage per permission as two flags on the role ↔ permission link (as OSS), with manage including view. And 17.2–17.3 did the same for the admin side: admin permissions live in their own tables and seeder, in the same style, and the fifteen admin groups are published (Dashboard · User management · Organizations · Servers · Premium Hosting Care · Alerts · Referrals · Codes · DNS · Site settings · Integrations · Plans · Settings · Debugging · Add-ons) | The sidebar being backend data is the real news, and it lands on four things the frontend doc fixes: the main sidebar order, the server menu (U13.4), the app menu (U14.4) and the page-paths map. D-55 raised with a [!CONFLICT] on FE: Permissions & role matrix — nothing overwritten, because the two sides are not arguing about content, only about who holds the sequence; the ask is that the seeder be written from the agreed menus. Navigation structure is marked as intent rather than design, keeping what is genuinely ours: badges, the plan-locked treatment, active state, collapse. Lucide names are a happy fit — already the frontend's icon set — but need a curated name → component map with a fallback, not a whole-set import. D-50 narrows a long way: the admin navigation is now specified, the shell still is not. Three new admin screens appear in the group list and nowhere in 17.1–17.23: an Alerts area (server usage, load averages), Debugging → queue size, and a single Add-ons area for the WP Toolkit / Reseller / Log Monitoring admin halves. And one of my own objections is withdrawn: an hour ago this site said 18.9's top-referrers list was stranded in 17.19's settings — Referrals is its own admin group, so it has its own page, exactly as asked. Integrations → SMTP and social keys are recorded but deliberately not proposed for the flow doc: Bhavik removed those admin sections on purpose. Also updated Roles & permissions, Missing backend, FE: Admin panel, FE: Referral & Affiliate. Pending entries 16–17 added, 12 updated; the flow doc was not touched |
| 2026-10-08 07:48 | Pair 2 added a whole new phase: Phase 18 — Referral & Affiliate (Pair 1 unchanged). It separates the two halves this site has always named together. Referral stays in Central and works as V7: a personal link with counted clicks, the new user's credit at sign-up (if the referrer is active), the referrer's credit once their referral takes a paid plan and pays a minimum amount, a referral page of four facts, admin settings inside 17.19 plus a top-referrers list, one notification and two activity-log entries. The affiliate programme is gone from Central: it runs in Tolt, which already replaced V7's built-in system in production in 2024. Central only saves the Tolt code from the sign-up link and sends it with Stripe payments. 18.3: no affiliate dashboard, no commission slabs, no payouts. V7's apply form, approval, slabs, PayPal payouts, banners and custom links are not in V8. 18.12 answered minutes after publication: both count, as separate rewards | New page: FE: Referral & Affiliate. It corrects this site's own row from four hours ago — the morning's "affiliates dropped admin-side only, user-side affiliate kept" was read here as the user keeping an affiliate area, and 18.3 says there is none; the correction is written on FE: Admin panel rather than quietly swapped. The clean way to say it: referral pays credit, affiliate pays money — which is exactly why one stayed and one left. D-23 is now down to the AI assistant alone, after support tickets were cancelled earlier today. 17.19's referral setting gains its four fields, and its top-referrers list is flagged as a report in a settings page — the wrong home. D-54 raised and closed in the same run — Pair 2 rewrote 18.12 mid-sync, caught by the re-diff before marking done: both codes count, as separate rewards. Either way the frontend doc's "affiliate code wins" is wrong, because it answered a question about the built-in affiliate, which no longer exists. Also updated: Product overview (out-of-scope list down to one), FE: Notifications & mail, FE: Billing screens, FE: Account screens, FE: Auth screens, V7 migration. Pending entry 15 added and entry 14 rewritten; the flow doc was not touched |
| 2026-10-08 07:18 | Both docs changed, and Jayshree settled three things. Pair 1 published the permission list — new 4.9 (37 keys), 4.10 (parents) and 4.11 (seeder) — taking Phase 4 to requirements complete and answering its own Q1: manage includes delete, no separate delete permission. V7's 92 permissions are mapped with never less access. Jayshree's rulings, now in both docs: 7.21 extra servers is in and "free forever" is gone (7.3 updated to match); the White label owner's own SMTP is restored to 12.10 with a test email; affiliates are dropped only from the admin panel — the user-side affiliate is kept for a Referral & Affiliate phase. And support tickets are not in V8 at all — no Support phase, the three ticket emails and two notifications dropped. Pair 1 also took Pair 2's Phases 13, 14, 15 and 16, so the two docs now agree on Phases 3–17 | New page: FE: Permissions & role matrix — nine pages here had carried "the permission names are not published" since 2026-10-03, and all nine are rewritten. The names let the role matrix become a real form: three states per row, and manage covering delete settles its width. Three conflicts closed, one of them mine from this morning. 7.21 was flagged [!CONFLICT] six hours ago and is now plain V8 requirement — the callout on FE: Plans & subscription is a resolution note, Servers loses its provisional caveat, Subscriptions marks free_forever removed for good, D-49 keeps only its real half, and pending entry 9 is off hold. The SMTP row has now moved three times in three days — answered, withdrawn, restored — and this page says so rather than tidying it away, because that history is the reason not to trust a single day's deletion. Two answers came free: 4.11 says the Control Panel uses this same permission list, closing an item FE: Control Panel & White label had marked unpublished; and Phase 17's numbering gap closed, since 14–16 are the three add-ons. Two decisions raised: D-52 (blueprints, backup storage and the plan page have no permission key) and D-53 (one server key covers delete, resize and change IP). Also updated: FE: Notifications & mail, FE: Admin panel, Blueprints, Open questions. Pair 1 edited 4.11 again at 07:17, mid-run — permissions live in the seeder, not a config file, and each carries its parents, owner-only flag and order, with labels from translation files; caught by the re-diff before marking done, and folded in. Pending entries 12–14 added; the flow doc was not touched |
| 2026-10-08 07:10 | Pair 2 caught up with Pair 1 — and declined one item. It copied the Ubuntu decision (8.1, 8.7), the whole Phase 9 revision (add-only database engines, root SSH, the web-server config test, deleted-server backups, 9.28 alerts, 9.29 change IP, 9.30 PHP-FPM, rules renumbered to 9.31–9.33), 10.1's nip.io temporary domain and Phase 17 — Admin panel; a section-by-section check shows Phases 9 and 17 are now identical in both docs. Phase 16 is marked ✅ complete. But 7.21 it did not take: Pair 2 still says "free forever" and attaches "Pair 1 decision (2026-10-08) — differs, to confirm with Jayshree". Smaller: "moving server subscriptions on transfer" now points at Phase 7 rather than "the billing phase" | The 7.21 disagreement is the one that matters, and it makes yesterday's work provisional. Phase 7 is Pair 2's own phase, so Pair 1 changed an item inside someone else's — and the owner has not agreed. This site still describes extra servers, because it is the newer and far more detailed rule, but it now says so provisionally: a > [!CONFLICT] on FE: Plans & subscription, a caveat on the plan-limit row in Servers, the struck-through free_forever state on Subscriptions marked as possibly returning, D-49 opened with the disagreement, and the pending entry flagged hold so nothing is applied to the flow doc meanwhile. One rule survives either outcome: the usage display must show the API's real allowance, never a bare plan number. The cross-check is otherwise clean — everything else Pair 1 wrote this morning is now in both docs. FE: Organization & Members records the subscriptions-on-transfer pointer, and FE: WP Toolkit its completed status. The flow doc was not touched |
| 2026-10-08 06:55 | Pair 2 filled the gaps in Phase 16 (Pair 1 unchanged), taking it to 16.1–16.15 — all of it user-visible. 16.1: two ways to pay, as 14.1. 16.3: when it ends the toolkit stays installed, so buying again works straight away. 16.4: there is a per-server status — installed / failed / version — with automatic retries, a Retry button and an email after repeated failure. 16.5: the tab is shown only in Central and only on normal, active WordPress apps — never a WordPress-in-Docker app. 16.8: deleting an app deletes its saved Object Cache Pro key. 16.10: view / manage permissions like any app feature, plus a White label owner can tick WP Toolkit for their Control Panel customers — working only while the owner has the add-on. 16.11: the admin can also edit one user's cycle, price and expiry. New: 16.13 a locked tab with the price and Buy before purchase · 16.14 notifications (bought, renewed, expires soon, expired, install failed) · 16.15 no discounts for now | One correction to this page's own words: it said a few hours ago that WP Toolkit has "no install screen". There is still no install action — but there is a screen: a per-server status list with Retry, so the honest description is no install step, but a visible result. 16.13 settles a question this spec had left open on a neighbouring page: Premium Hosting Care's 14.6 allowed "hidden or locked" and this spec recommended locked; the backend has now chosen exactly that for WP Toolkit, so FE: Premium Hosting Care cites it as the precedent and the two should not differ. D-51 narrows to where, not what — the state is settled (locked, price, Buy) and so is when the tab exists at all. And 16.10 names the first real entry in Phase 12's unpublished permission list (12.3), with a consequence worth designing for: a Control Panel customer can lose WP Toolkit because the owner's subscription lapsed, which the panel must explain as the owner's doing. Smaller: no discount line at all on the buy screen (unlike 14.2's two prices), and the V7 email map gains a WP Toolkit row on FE: Notifications & mail. sync/pending-frontend-changes.md entry 11 updated throughout. The flow doc was not touched |
| 2026-10-08 06:40 | Pair 1 split Phase 17's DNS item in two (Pair 2 unchanged). 17.21 is now ServerAvatar's own DNS, admin-managed but legacy only: it keeps old V7 temporary, phpMyAdmin and file-manager records alive — updating them when a server's IP changes and deleting them when the app or server goes — and admins cannot add new ServerAvatar temporary domains at all. 17.21a is new: each White label owner's own DNS, set by the owner in their own White label setup (12.10a), serving their customers' temporary domains, not ServerAvatar's keys and not managed in the admin panel — admins can only view it for support | This corrects what this site published yesterday. FE: Admin panel had treated White label domains as something ServerAvatar's DNS served; they are the owner's, and the admin side only looks. Both rows are now written separately, and the same correction went to FE: Control Panel & White label, where 12.10's DNS note had the same conflation. Two consequences for whoever builds these: ServerAvatar's DNS screen has no "add" action at all — unusual enough to say on the screen rather than leave an admin hunting for the button — and the owner-DNS view is read-only, with someone else's credentials in it, which should be obvious at a glance. sync/pending-frontend-changes.md entry 10 gains the same distinction, so nobody designs one screen for both. The flow doc was not touched |
| 2026-10-08 06:30 | Pair 1 trimmed Phase 17 while this sync was running (caught by re-reading it before marking done): admin server installation logs are removed from 17.12 and listed as not in V8 | Small, and it takes work away rather than adding it: FE: Admin panel has no log viewer to build, so support reads the install's own progress and failure reason (8.9) instead. The admin server page keeps one admin-only extra — reboot through the cloud provider, which does not go through OSS and therefore works when the panel does not. sync/pending-frontend-changes.md entry 10 corrected the same way. Also fixed here: a source-table date in this sync had landed on the wrong row — Pair 2's and Pair 1's "last change" times are now right (06:13 and 06:20) |
| 2026-10-08 06:25 | Pair 2 added Phase 16 — WP Toolkit add-on (16.1–16.12; Pair 1 unchanged), 🟡 with the billing cycle, maintenance mode and the V7 Object Cache Pro migration marked not final. It runs like Log Monitoring — a program on the server, OSS running its commands — but Central installs and enables it automatically, so there is no install screen; it is bought per account, recurring, covers every WordPress app on every server, and when it ends the screens lock while the sites keep working. Blueprints turn out to live in Central | New page: FE: WP Toolkit — and two questions this site has carried for days are closed. D-15 (who installs and licenses WP Toolkit) is answered: Central does it by itself on purchase, and it is a paid per-account add-on. D-39 (do blueprints exist in V8) is yes — and in Central, matching Bhavik's own decision, so Blueprints and FE: Application screens lose their uncertainty callouts. But blueprints are narrower than this site assumed (plugins and themes applied at creation, not V7's wider set, and no run against an existing site), so that page is marked for rewriting rather than quietly left wrong. D-51 raised — this is the largest group of controls in the app panel and the fixed app menu has no place for it, with the extra wrinkle that maintenance mode may leave the add-on. A risk worth reading in the backend's own words: its chosen option leaves V7 Object Cache Pro sites on the old shared-Redis setup and says they may silently stop caching; the backend suggests the alternative. The frontend cannot fix it, but the Object Cache Pro screen must then show a site's real state rather than just "on". sync/pending-frontend-changes.md gains entry 11. The flow doc was not touched |
| 2026-10-08 06:10 | Pair 1 published Phase 17 — Admin panel (17.1–17.23), the first admin phase, same flow as V7 (Pair 2 unchanged). It also clarified 10.1: a new app's temporary domain is <app>.<server-ip>.nip.io with HTTPS from OSS, and Central creates no new temporary domains — White label keeps its own, as V7 | New page: FE: Admin panel, in the nav. Until today every admin page here was a guess from V7. Three things it answers: server transfer — 17.13 is an admin move with no user request flow, matching Bhavik's 2026-10-07 rule, so backend and frontend agree; temporary app domains come from nip.io via OSS, which closes a question open since Phase 10 and explains why 12.10's DNS block exists at all (White label and legacy V7 domains only) — recorded on FE: Application screens and FE: Control Panel & White label; and the free managed server's partner list turns out to be an admin setting (17.22), another piece of D-41. D-50 raised — the phase specifies what each screen contains, not the shell it lives in, and with a role-built sidebar and every route permission-checked that shell is a decision to make now rather than later. One conflict flagged, not written: 17.11 gives the admin deleted servers & restore, which Bhavik ruled out of V8 for users — admin-only may be a different call. Also noted: a display-message banner the admin can put in front of every user needs a home in the user layout, and the referral program appearing in 17.19 gives the user-side referral screens their first backing. sync/pending-frontend-changes.md gains entry 10. The flow doc was not touched |
| 2026-10-08 05:55 | Pair 1 replaced "free forever" with "extra servers" (7.21; 7.3 and the Free-plan note follow). The admin grants a user 0, 1, 2… extra servers for their own servers, and the server limit becomes plan limit + extra servers. The extras stay when the plan changes — they belong to the user — and are not counted in downgrade checks (7.8). Managed servers keep their own counter (6.9). V7 free-forever users migrate to extra servers = 1, and the sign-up "free Pro server" setting is not in V8. (Pair 2 unchanged.) | This corrects a line this site had been repeating, including through the D-32 argument: that the plan's own figure was the whole server allowance. It is not — it is plan + extras — so Servers says so plainly now, and FE: Plans & subscription requires the usage bar to show both parts rather than one total, because a user with extras otherwise sees a number that matches no plan. D-32 itself still stands: the "+3 per payment" belongs to the managed-server counter; what changed is that a different grant does land on the plan side. The free-forever screens are withdrawn — no badge and no "no renewal date" variant on FE: Plans & subscription or Subscriptions, and Plans now explains V7's free single server as an extra server, which also closes an Open question row there. D-49 raised: "not counted in downgrade checks" reads two ways — the check ignores the extras (blocking someone whose servers only fit because of them) or they simply carry over. The two give different blocking messages, so neither is written. sync/pending-frontend-changes.md gains entry 9. The flow doc was not touched |
| 2026-10-07 14:55 | One line, and it is about ownership rather than rules (Pair 2 only; Pair 1 unchanged). Phase 15's "Not final" block gained: "Jayshree will decide these points when implementation of this phase starts." The four points themselves are unchanged — the install method (Git app now, possibly a Docker image), the Redis connection OSS may or may not expose, adding a server from inside the panel having to follow Phase 8, and whether V7's switched-off "update available" email returns | Recorded on FE: Reseller panel, with the distinction kept honest: having an owner and a moment does not make it decided. What it does change is the shape of the risk — this is now sequencing, not an unknown, the same shift Phase 13's OSS work made at 07:47. So the page still refuses to build the install screen around either method, because a Git deploy and a Docker pull fail and progress differently, but it no longer reads as an open hole. Also noted on the page: of the four points, only the "update available" email would reach a screen — the other three are decisions behind it. No new conflict, no new open question, and nothing else on the site needed changing |
| 2026-10-07 12:55 | Pair 2 added Phase 15 — Reseller panel (Pair 1 unchanged): V7's "Self-hosted" panel as a lifetime licence plus a panel Central installs on the reseller's own server and domain as an ordinary Git app through the OSS API, activated inside the panel itself with one domain per licence, with change-domain by email confirmation, an Update that redeploys, and a Delete that frees the domain. The backend marks the install and update flow as not final (a Docker image is the named alternative). Separately, Bhavik set four V7-alignment rules at 11:58, three of which contradict the published backend | New page: FE: Reseller panel, in the nav — and with it all four add-ons named in 7.26 are written, two of them lifetime. D-48 raised for where its page and Install live. The bigger item this sync is the three disagreements, which are flagged, not applied: (1) email is primary — Bhavik says account, billing and plan notifications are email only and the new V8 emails must not be added, while backend 11.8 makes those events routable to channels and 11.23 lists the emails by name → > [!CONFLICT] on FE: Notifications & mail, with a note that his rule makes §C smaller, not bigger; (2) deleted servers + Restore and deleted-server backups are not in V8, while 9.6 and 9.21 specify both → callout on FE: Server screens, and the consequence named: Delete becomes final, so its confirm is the most consequential in the server screens; (3) "Log Monitoring is handled by the Central Panel, never OSS", while Phase 13 says the OSS backend runs the toolkit → callout on FE: Log Monitoring, where I also offer the likeliest reading: from the user's side it is a Central feature and only the collection happens on their server, so both may be true at different levels. Nothing was rewritten on either side. The fourth rule — server transfer stays V7's admin-only, no user request flow — needs no change, because this site never specced one. sync/pending-frontend-changes.md: entry 8 added for Phase 15, and the deleted-servers bullet withdrawn from entry 4 as instructed. The flow doc was not touched |
| 2026-10-07 11:55 | Pair 2 finished Phase 14 (Pair 1 unchanged) with three clarifications that all reach a screen. 14.1: there are two ways to pay — from the credit balance, or straight through a gateway in one step, where the payment adds the credit and the pack is bought automatically on return. 14.2: the discount applies only when paying from credit. 14.6: the per-app switch lives in the app's Settings tab, is a Central-only option that is hidden or locked without the add-on, and both the switch and the check results are saved in Central — OSS is not involved; an app deleted in OSS is turned off. Four rows of the V7 email and notification maps were pointed at this phase, and "extended support inquiry" is dropped in V8 | 14.1 and 14.2 together make one real design problem: the same pack costs more if you pay by card. So FE: Premium Hosting Care now says the confirm must show both prices side by side — discounted from credit, undiscounted direct — rather than letting the user find out on the receipt. The direct route also ends somewhere unusual: the user returns from the gateway to a pack already bought, so that screen has to confirm both things happened and not look like a top-up that did nothing. D-47 is half answered — the switch has a home (Settings), though Settings is itself one of D-40's unplaced app tabs, and nothing says where the status is shown. On "hidden or locked", the backend allows either and this spec recommends locked with the add-on named, since the user can act on it immediately — which is when an upsell is honest rather than annoying. It also answers a question worth having asked: this monitoring is not an OSS feature at all, which is exactly why it survives an unreachable panel. FE: Notifications & mail records the four resolved map rows. The flow doc was not touched |
| 2026-10-07 11:25 | Pair 2 added Phase 14 — Premium Hosting Care (Pair 1 unchanged). V7's managed-support pack: a private Slack support channel the support team opens by hand, and proactive uptime monitoring the user switches on or off per app, where Central checks the app's public address from outside every 7 minutes and alerts only when the status changes. It is bought per account for 1, 6 or 12 months, paid from credit with tax, has its own expiry date with auto-renew (the same engine as plans), and a Cancel that runs to the end. Prices, renew price and discounts are admin-managed. phpMyAdmin apps are skipped, an SSL error that still answers 200 is never alerted, and V7's "X of Y sold" counter is gone | New page: FE: Premium Hosting Care, in the nav. The useful finding is that all three add-ons with phases now end differently — never (White label), on a downgrade (Log Monitoring), or on their own expiry date (this one) — so the add-ons page needs three card shapes and none of them can be copied from another. 14.6 is also the only app screen in this spec that does not go through the OSS panel, which makes it the one view that survives an unreachable panel and the only place the user sees their site from outside. D-47 raised: the per-app switch and its status have no place in the fixed app menu. It also explains an older line: 7.26 called Premium Hosting Care "not assignable" to a plan, and 14.1 says why — it is per account with its own expiry, so a plan has nothing to grant. Premium Care came off the deferred lists on FE: Notifications & mail, FE: Plans & subscription and Product overview; D-23 now says three of its seven features have phases and names the four that do not. Prices are not written on the page — the admin owns them, the same rule this spec follows for plans. sync/pending-frontend-changes.md gains entry 7. The flow doc was not touched |
| 2026-10-07 09:40 | A quiet deletion that reverses an "answered" item (Pair 2 only). SMTP and its test email were removed from 12.10, and Phase 11's "White label's own SMTP comes later, with the White label phase" line was deleted with it. Nothing replaced either. So a White label owner has no own-mail setting — and it is not deferred either, because the line that deferred it is gone | This had been on the site as "answered" since 2026-10-06, so the reversal is recorded rather than quietly dropped — struck through on FE: Control Panel & White label and on FE: Notifications & mail, whose Existing-users row now reads withdrawn, after a day as answered. The Settings tab loses a group and its mail test, so there is less to build here than this page described yesterday. And one open item raised, because the gap is real and nobody has filled it: whose address do a white-label owner's customers get emails from? A branded panel on the owner's own domain that emails from serveravatar.com undoes part of the point — the doc no longer says, and nothing is invented here. The flow doc was not touched |
| 2026-10-07 08:25 | Pair 2 added three items to Phase 13 (Pair 1 unchanged), all user-facing. 13.10 Low disk space: as V7, with less than 5 GB free the toolkit stops collecting to protect the server; Central shows a warning on the server and emails the owner the free and total space; collecting restarts by itself once space is freed. 13.11 Notifications: install, update, remove and low disk space go out through Phase 11, as V7. 13.12 Logs not readable (new): if an app's log file cannot be read, Central shows a small warning on that app so the user knows why its reports are empty. Two rows of the V7 email map were resolved with them — InsightHub disk issue → 13.10, "monitoring domain change" dropped — and the V7 notification "log monitoring suite updated" → 13.11 | This answers a question this page had been asking since the phase appeared. It had said "collecting data" must explain why it is empty; the backend now supplies the reasons, so FE: Log Monitoring has a new section D with three distinct empty states — collecting data (wait), logs not readable (this one app), low disk space (this server, clears itself) — plus "licence required", which is a refusal, not an empty state. The disk rule needs restraint: it fixes itself, so the screen must not offer a resume button — name the free space and point at the server's Disk cleaner (9.20). And because the warning lives on the server while the empty reports live on the app, the app's empty state must name the server-level cause instead of leaving the user guessing. 13.11 means the low-disk message arrives twice (notification and server warning), so both should read the same way; which group it joins is not stated and is not invented here. FE: Notifications & mail records the two resolved V7 map rows. Also fixed on this page: the Source documents table had been stale since 2026-10-05 — its "Last change" dates and both descriptions still said Phase 8 was a pointer and Pair 1 the only home of Phase 6. Rewritten to the truth: Pair 2 carries Phases 1–13 and owns 7, 10, 11, 12, 13; Pair 1 wrote 1, 4, 6, 8, 9; and Pair 1's Phase 13 is behind. The flow doc was not touched |
| 2026-10-07 07:55 | A small change with a real effect on planning (Pair 2 only). Phase 13's two OSS dependencies stopped being open gaps: the status line moved from "2 things needed from the OSS team" to "OSS team informed — they add 13.3 and 13.5 during development", and the list heading from "Needed from the OSS team" to "OSS team (informed 2026-10-07 — handled when development starts)". The two items themselves — install / update / remove of the toolkit, and running fetch and prune from OSS's own scheduler — are unchanged | Reframed on FE: Log Monitoring, because the earlier wording was stronger than the facts now warrant. This page had called them Missing work that "cannot be built" and said the collection gap "could quietly ruin the feature". They are now scheduled work with an owner, so they read as sequencing, not blockers: Central's screens can be designed and built against them, and the reports simply have nothing to show until the schedule exists. The one frontend consequence that survives unchanged is worth keeping: "collecting data" is a state the design must carry properly, and it should say why it is empty rather than looking like a slow first run. I also added a fact that failed to save in the previous sync — V7's InsightHub agent service is gone and nothing runs on the server by itself, which is why every screen here needs the panel reachable. sync/pending-frontend-changes.md entry 6 carries the same reframing. The flow doc was not touched |
| 2026-10-07 07:40 | Pair 2 rewrote Phase 13 a third time (Pair 1 unchanged), this time around how it actually runs. V7 kept an InsightHub agent service alive on every server; V8 has no separate service — the toolkit is a command-line program and the OSS backend runs its commands, passing the answer back to Central. The numbering settled at 13.1–13.9: collecting the logs became its own item, 13.5 — fetch every 15 minutes, prune daily at a 7-day default — so reports moved to 13.6, update to 13.7, remove to 13.8 and the activity log to 13.9. Three real changes came with it: update keeps the collected data (remove still deletes it), deleted apps are removed by OSS itself, and "collecting data" replaces zeros before the first collection. The phase now lists two things needed from the OSS team, not one | FE: Log Monitoring renumbered and revised. The important find is the second OSS gap: install can succeed, apps can be registered, and still nothing collects until OSS schedules fetch — so "collecting data" may not be a passing state at all, and the screen has to be honest about why it is empty rather than looking like a slow first run. The wording change matters too: a message, not a grid of zeros, because a zero is a legitimate value and a user cannot otherwise tell a quiet site from a broken install. Update keeping the data is now stated on the screen, since the neighbouring Remove deletes everything and users who read that warning will assume the worst. Also corrected: the page had said my own "zeros are not an error" reading, and that the V7 agent's database was removed at migration — it is the agent service. sync/pending-frontend-changes.md entry 6 carries all of it. The flow doc was not touched |
| 2026-10-07 05:55 | Phase 13's last open point is answered, and Pair 1 caught up. Pair 2 marked the phase ✅ complete and settled 13.7: removing the toolkit unregisters every app, stops both jobs, removes the program and deletes its database with all collected statistics — installing again starts fresh, and a plan downgrade does exactly the same on every server. The "open point" section is gone. Pair 1 copied Pair 2's 7.26 White-label exception and the whole of Phase 12 (identical) and Phase 13 — though its Phase 13 is one revision behind, still showing the old 13.7 and the 🟡 status | The answer turns a disconnect into data loss, so the screens change shape. FE: Log Monitoring: Remove is now a type-to-confirm that says all collected reports are deleted and that reinstalling starts from zero — there is no export — and the phase's open-point row is struck through as answered. The harder half is the one the user does not initiate: a plan downgrade deletes the same data on every server, so FE: Plans & subscription now says the downgrade warning must say reports will be deleted, not just monitoring will stop. Cross-check: Phase 12 is word-for-word identical in both docs, and the traceability row now covers Phases 6–13 — with Pair 1's Phase 13 lag noted, since Pair 2 is the primary doc and this site follows it. sync/pending-frontend-changes.md entry 6 updated with the same two points. The flow doc was not touched |
| 2026-10-07 05:40 | Both docs changed, and the flow doc became report-only. Pair 1 settled two Phase 8 questions: the Ubuntu version is 22.04, 24.04 or 26.04 (20.04 is out, and the installer refuses anything else), MongoDB is not available on 26.04, and the unclaimed server case is not in V8. Pair 2 changed Phase 13 again: 13.4 now registers all of a server's apps automatically and there is no per-app on / off — monitoring covers every app on the server, as V7 — so the per-app entries left the activity log (13.8) too | This site's pages are updated as usual; the frontend flow doc is not touched any more — Bhavik's 05:26 decision. What it would need is written up as screens and flows in sync/pending-frontend-changes.md, with the three new items at the top and the Phase 9 / 12 / 13 material he removed listed below them, each re-proposable. On Phase 8: the MongoDB limit is the part that reaches a screen — MERN and 26.04 cannot be chosen together, so the two fields must constrain each other before Review; for an own server the version check belongs in the pre-check. Updated FE: Add a server, Servers and FE: Integrations, and removed both items from the still-open lists. On Phase 13 I had to correct myself again: an hour ago this site described the per-app switch as "an off switch for exceptions" — the switch is gone, so FE: Log Monitoring now says there is no per-app control to design and the only way to stop monitoring is to remove the toolkit from the server. Said plainly on the page rather than quietly edited |
| 2026-10-07 05:30 | Pair 2 rewrote Phase 13 within the hour (caught by re-reading the doc before marking done) to follow how OSS actually runs it. Real additions, not wording: the install now checks whether the toolkit is already there and which version, and installs a program, a settings file and its own database plus two jobs — fetch every ~15 minutes and prune at a retention default of 7 days; each app is registered with its name, system user, domain, web server and SSL, and domain or SSL changes update the registration; there are 49 reports, some taking a limit, a field or a status code, OSS caches each answer briefly, and zeros before the first fetch are explicitly not an error; a refused licence returns "licence required"; update ends with a one-off bot-detection re-check; and the open point is now published — on remove, keep V7's behaviour of deleting everything, or keep the data so it continues where it stopped. Numbering moved: update 13.6, remove 13.7, activity log 13.8 | FE: Log Monitoring revised to match, and one of my own notes corrected: the page said the "open point on keeping data" was unpublished — it is published now, with both options spelled out, so the row says what the choice is instead. Three things became real screen states rather than guesses: "collecting data" (the backend went out of its way to say zeros are not an error, which matters because the first 15 minutes after an install would otherwise look broken), "licence required" (and since recognition is by IP while 9.29 lets the IP change, that is the likeliest way a user meets it), and "already installed, version X" as a third entry state for the install screen. Per-report options replaced the single global filter I had assumed. Two new open items: whether the retention days can be changed, and what happens to apps created directly in the OSS panel — 13.4 only promises automatic registration for apps created through Central. Frontend doc: U21's screens, states and flows follow the same corrections |
| 2026-10-07 05:25 | Pair 2 added Phase 13 — Log Monitoring add-on (Pair 1 unchanged). V7's InsightHub returns as reports inside Central: the add-on comes with a plan or is bought, is enabled automatically when an eligible plan is paid, and is tied to the plan — a downgrade switches it off and removes it from every server. The user installs a toolkit per server (live progress; needs an OSS install API), after which the server's apps are monitored automatically with an on / off per app, and the reports — Dashboard, Traffic, Errors, Bots, User Agents, Bandwidth, about 50 of them with date range and limit — appear in the Application panel. V7's separate InsightHub app and its domain are dropped. The phase is marked 🟡 because it needs the OSS team | New page: FE: Log Monitoring (in the nav), and the add-on lists on Product overview, FE: Application screens and FE: Notifications & mail no longer call it later work. The useful finding is a contrast: the two add-ons that now have phases behave in opposite ways — White label is lifetime and cannot be switched off, Log Monitoring is removed from every server on a downgrade. FE: Plans & subscription now says which is which, and 7.8's warning names the servers that would stop being monitored. D-46 raised — the reports want a place in the fixed app menu and the install action in the fixed server menu, and neither has one; it is the biggest placement question so far, and these reports have no OSS screen to copy. Two things named instead of guessed: the licence recognises a server by IP while 9.29 lets that IP change, and 13.6 refers to "the open point on keeping data" that is not in the published phase. Frontend doc: U21 is rewritten from a one-line V7 stub into the real module — status, five screens, screen states and four flows — plus open question 23 and a V7-vs-V8 row |
| 2026-10-07 05:10 | Pair 1 checked Phase 9 against V7 and revised it (Pair 2 unchanged). One correction: database engines are add only — no remove, because OSS has none. Six additions: root SSH access per user (9.11), test the web server config before restarting (9.15), backups of deleted servers stay listed and downloadable (9.21), server alert limits — CPU, memory, disk, load (9.28), change the server's IP in Central (9.29) and PHP-FPM config (9.30). The three rules moved to 9.31–9.33. Newly named as pending decisions: site migration and restoring a backup to another server; workers stay app-level (10.14) and reconnecting after a broken link joins the refresh decision (Phase 8). Four of the new or changed items say needs OSS API support | D-37 is half answered: the per-server alert limits now have a real home in 9.28, so FE: Server screens stops guessing at Server → Settings and Open questions narrows D-37 to the channels screen of 11.7 — which Phase 9's menu still has no item for. D-45 grew by one: PHP-FPM config joins Docker, Panel update and Service monitoring as specified-but-unplaced, and Change server IP needs a home too. Two items change a screen's shape rather than adding a control: add-only engines make installing one a permanent act, so it is a CONFIRM with no delete action afterwards; and deleted-server backups outlive their server, so they cannot live only under a server that no longer exists — the backend does not say where they go, and this spec does not choose for it. Five of the phase's screens are now blocked on the OSS side, not on Central (9.11, 9.26, 9.27, 9.28, 9.30) — recorded on Missing backend dependencies. Frontend doc: U13 gains Server alerts, Change server IP and the deleted-server backups note, question 12 loses its alert-limits half, question 22 gains PHP-FPM, and the Pending row for site migration now says the backend has named it. (Pair 1's change-log also says "support tickets removed", but nothing in the published text changed — the support-phase email rows are untouched, so there was nothing to act on.) |
| 2026-10-06 12:10 | The one open disagreement between the two backend docs is gone. Pair 2 rewrote 6.4 and 6.9 to match Pair 1 exactly: every successful payment, including auto-recharge, adds +3 to the managed-server limit, and 6.9 carries the whole rule — trial and cloud-hosting accounts cannot exceed it, it starts from an admin setting (default 1, 10 for redeem-code signups), the admin can change it, and it counts managed servers only. The note saying the bonus had been dropped is deleted, and Phase 6 is now identical in both docs. Pair 2 also clarified 12.10: the White label panel settings are saved in Central at account level, not through the OSS API. (Pair 1 unchanged.) | The Conflict raised at 09:00 is retired — the callout on FE: Billing screens §A is now a plain note recording that the docs disagreed for three hours and settled on Pair 1's version, which is the one this site had followed from the start. Nothing about the screens changed, and D-32's answer never moved: the limit counts managed servers, nobody can create one (D-36), so it stays invisible and the plan's number is still the only limit a user meets. Badges flipped from Conflict to V8 requirement on Billing, Servers, Missing backend dependencies and Open questions. 12.10's clarification settles which API those screens use — Central's own, so a server being offline must not block them (FE: Control Panel & White label). This was the only backend-versus-backend conflict on the site; it is closed. The remaining Conflict marks are all the other kind — Bhavik's decisions against the backend (D-2 organizations auto-created, D-26 login before verification, D-27 integrations level, D-36 managed servers) plus the new D-44 palette question, and those stay until someone decides them |
| 2026-10-06 11:58 | Pair 2's doc changed once more while this sync ran (caught by re-reading it before marking done) — this time a cross-check, not a new rule: Pair 2 copied Pair 1's Phase 8 and Phase 9 in full, replacing its two "see Pair 1's doc" pointers, and removed Q1 and Q2 from its open-questions list now that 8.10 and 8.11 answer them | Nothing to change, and that is the finding. A section-by-section diff shows Phases 8 and 9 are now byte-identical in both docs apart from the (by / from Pair 1) label, so the two newest and largest specs on this site — FE: Add a server and FE: Server screens — no longer rest on a single source. Pair 2 dropping Q1 and Q2 also confirms the call this site made at 06:05, when both were moved out of Open questions into the answered table |
| 2026-10-06 11:55 | Pair 2 finished Phase 12 — status moved from requirements written to requirements complete, with the last three items: 12.4a find a server's Control Panel user by the server IP; 12.10c show the owner the exact redirect / callback URLs, built from their own domain, for their GitHub / GitLab / Bitbucket and cloud-storage apps; and Dropbox skipped in the Control Panel for now, as in Phase 5. (Pair 1 unchanged.) | Three small items, one of which matters more than it looks: the callback URL changes when the owner connects their custom domain, so FE: Control Panel & White label specifies it as read-only, copyable, read from the API, and labelled as "this will change" while the owner is still on the default manage domain — otherwise owners register a callback that stops working. 12.4a is placed in the search owners already use rather than as its own screen, since the server list already searches by IP (9.1). Dropbox needed no new decision — it is the same Q11 answer already on FE: Integrations, reused. Frontend doc: U18's Settings screen and White label flow now mention the callback URLs, the preview and the DNS records, the Control panel screen can be found by IP, and the customer's Git / storage step says Dropbox is left out. No new conflict and no new open question |
| 2026-10-06 11:50 | Pair 2's doc changed again while this sync was running — caught by re-reading it before marking the sync done. 12.11 was rewritten a second time: at 10:27 a plan change or expiry switched White label off; at 11:09 only an admin could; at 11:37 there is no on / off switch at all, the same as V7. An "admin side" line that arrived with the 11:28 items was removed again in the same edit | Both earlier versions of this page were wrong, and both corrections are on the page rather than quietly replaced. The practical result is simpler than either: there is no "switched off" state to design — no paused banner, no admin screen to wait for, and no warning anywhere in the plan flow about losing White label. Fixed on FE: Control Panel & White label (12.11, the states table, the intro and the answered-questions row), FE: Plans & subscription 7.26, the frontend doc's U18 and its V7-vs-V8 row, and the two rows above that this sync had already written. The only unknown left in the item is what happens to the custom domain's certificate, which no version mentions |
| 2026-10-06 11:45 | Both docs changed, and one of them finished the phase this site had been waiting on longest. Pair 1 published Phase 9 — Server panel features (9.1–9.30): the server list from Central's own data (search, filter, sort, 12 per page), shared-with-me, deleted servers & restore with no time limit, power on / off and resize for managed servers only, delete with an optional provider deletion, disconnect that leaves the server running and has Central ask OSS to revoke its own token, tags left as a pending decision, every menu screen (dashboard, databases, system users, firewall, Fail2ban, cron, services, PHP, Node, Docker, logs, disk cleaner, backups, settings, server sync, panel update, service monitoring, default web page, DB root password) and the rules for plan limits, permissions and the activity log. Pair 2 filled in Phase 12's V7 detail: customer Git and storage with the owner's keys, allowed app types, activity-log entries, DNS details, default-page preview, and a private partner link that creates a Control Panel user | New page: FE: Server screens (in the nav). Three things this site had flagged are now answered: the key-stays-valid warning on Servers is replaced by 9.8's token revoke, with the offline panel treated as a partial success; deleted servers + restore stops being a parked V7-only feature and gets /servers/deleted; and resize is kept for migrated managed servers. D-13 closed — the "Servers phase" it waited on is written end to end. D-45 raised: Docker, Panel update and Service monitoring have no place in the fixed server menu. D-37 is sharper: Phase 9's menu has no Notifications screen at all, while 11.7 puts channels there. Updated Server list & details, Missing backend dependencies and Open questions. On Phase 12, FE: Control Panel & White label gained six items and a note that 12.12 may be the other half of D-41 Assumption — Pair 1 still calls that login "open", so the two are not merged. Frontend doc: U13 is now 🟢 READY with four new screens, /servers/deleted joins the path map, the Pending table lost its first row, U20 records that the backend has tags "pending", questions 10 and 17 are Resolved, question 4 lost its resize part, question 22 is new, and two V7-vs-V8 rows were added |
| 2026-10-06 11:30 | One rule changed in yesterday's newest phase, and it is a reversal. Pair 2 rewrote 12.7 and 12.11 and added an exception to 7.26: White label is a lifetime add-on. A plan that carries it grants it once, after the user pays, and from then on it is on the account for ever — a later plan change does not take it away, and only an admin can turn it off. If an admin does, branding and the custom domain stop and the Control Panel keeps working on the default manage domain. V7 owners who have it keep it. (Pair 1 unchanged.) | This site said the opposite at 10:45 — that a plan change or expiry switched the add-on off — because that is what the backend said then. Corrected openly on FE: Control Panel & White label rather than rewritten in place, since the first version was published. Three knock-on fixes: the add-ons card reads Purchased, not Included, and shows no expiry; the downgrade check (7.8) must leave White label out, so FE: Plans & subscription no longer lists it as a blocker and its stale "Object Cache Pro" example was swapped for a plan-assignable one; and the switched-off banner now describes an admin action the owner cannot undo, instead of a pause they could end. The backend also dropped the line that branding and settings are kept for later — so that promise is gone from this site too. Frontend doc: U18's card states gain Purchased (lifetime), the White label flow says a plan change never removes it, and the V7-vs-V8 row now reads licence key → lifetime on the account |
| 2026-10-06 10:45 | Pair 2 added a whole new phase: Phase 12 — White label add-on (Pair 1 unchanged). Only half of it is the add-on. 12.1–12.6 is V7's Control Panel and every user gets it with no add-on: one customer login per server, app and database limits (0–2000), a permission tick-list, one-click login, and a customer panel that shows only that server using the Phase 10 app screens, with a 1-day session. 12.7–12.11 is White label: on for the whole account, branding (app name and folder name set once, "serveravatar" banned, brand colour → palette, logo / icon / favicon, header / footer, GA ID), the owner's own domain by CNAME with automatic SSL, and panel settings (SMTP + test, Git apps, cloud storage, DNS via Route53 / DNSimple, default server pages). If the add-on stops, branding and the domain pause and nothing is deleted. Customer passwords are now hashed (V7 kept them in plain text) | New page: FE: Control Panel & White label (in the nav), with the domain rule, both halves item by item, states and errors, permissions and what the customer's panel must not inherit. Three decisions raised, nothing assumed: D-42 — this is the first second signed-in surface in the product, for people with no Central account, served on the default manage domain and every owner's domain with branding per host, which is a hosting and routing call; D-43 — the fixed server menu (U13.4) has no Control Panel item; D-44 Conflict — 12.8 makes a palette from one brand colour, while Theme specifies a fixed, contrast-checked token set, so either generate a contrast-safe scale and preview it, or use the brand colour only where contrast is safe. One deferral closed: Phase 11's "White label SMTP comes later" is answered by 12.10, which also says where temporary app domains come from. White label was removed from the out-of-scope lists on Product overview, FE: Application screens and FE: Notifications & mail, and FE: Plans & subscription 7.26 now points at its phase. Frontend doc: U18 gains the White label screens and a Control Panel flow (the licence-key step was V7's and is gone), a customer-panel path block, two V7-vs-V8 rows, and open questions 19–21 |
| 2026-10-06 09:10 | Only Pair 1's doc changed, and almost all of it was catch-up: it copied Pair 2's Phase 7 additions (system vs custom plans, 7.12, 7.14, 7.26 add-ons), Phase 10 and Phase 11 in full, so those three phases are now identical in both docs. Two things were genuinely new: Phase 9 (Server panel features) is marked 🟡 "being prepared" — work has started, no rules yet — and Pair 1 recorded a deliberate disagreement with Pair 2 over V7's "+3 servers per payment": "Not taken: Pair 2's note in 6.4 dropping the '+3 managed-server limit' — Pair 1 keeps it." | No new screens — this sync was a check, and the check passed. Phases 7, 10 and 11 were specced from Pair 2 alone; a second doc now says the same thing word for word, so nothing on this site rests on one source. Added that as a traceability row rather than rewriting pages that were already right. One correction: this site had written that the two docs agreed about the "+3" after the 2026-10-06 reconciliation — they do not, and Pair 1 says the split is on purpose. Flagged as Conflict with a > [!CONFLICT] note on FE: Billing screens §A and corrected on Billing, Servers, Missing in backend and Open questions (D-32). We follow Pair 1, because Phase 6 is Pair 1's phase — and it changes no screen, since the limit counts managed servers and nobody can create one (D-36). Phase 9 row updated: it is the biggest gap left, and D-37 / D-38 wait on it. The frontend flow doc needed no change |
| 2026-10-06 06:40 | Both docs changed. Pair 1 corrected Phase 8 in three places: the free ServerAvatar Lite server (8.6) does not get the OSS panel at all — the phase goal now says so explicitly; "force cleanup" moved out of 8.3 into 8.7 and became optional for every way that installs on a server; and the automatic-token rule (8.10) was narrowed from 8.1–8.4 + 8.6 to 8.1–8.4. Pair 2 renamed two add-ons: InsightHub / Monitoring Panel → Log Monitoring, and Self-hosted panel → Reseller panel | One correction to what this site published yesterday: I had written "OSS is installed" for 8.6, following the backend's original wording — it is now the opposite, and the page says so rather than being quietly edited. That makes D-41 sharper: Lite has no Central account and no OSS panel, so none of our server screens could drive it even in principle. Also new on FE: Add a server: force cleanup is a tick-box the user chooses, which needs plain wording about what it removes — it is the switch that makes an existing server with Apache or MySQL usable. The rename was applied across FE: Plans & subscription 7.26, FE: Application screens, FE: Notifications & mail, Open questions, Product overview and the frontend doc's §16 — keeping the V7 names in brackets so older notes stay readable. Deliberately not renamed: "self-hosted GitLab" on the integrations pages, which is a Git host, not the add-on |
| 2026-10-06 06:24 | One clarification to 7.26. The examples of add-ons an admin can put in a plan changed from "InsightHub / log monitoring, Object Cache Pro" to "InsightHub / log monitoring, White label, Self-hosted panel", and the not-assignable list now spells out that Object Cache Pro is part of WP Toolkit rather than an add-on of its own | Small, but it settles a question the add-ons page would have hit: Object Cache Pro gets no card — it ships inside WP Toolkit. It also draws a clean line between a plan including an add-on (White label, Self-hosted, InsightHub → the card reads Included) and a plan merely gating who sees it (WP Toolkit → always bought, never included), which is how B7.26 and Bhavik's "other add-ons show by the user's plan" rule fit together. Updated the 7.26 rows on FE: Plans & subscription and this page, the add-on-phases line on FE: Application screens, and §16 of the frontend doc. No new conflict or open question |
| 2026-10-06 06:10 | Pair 1 published Phase 8 — Servers: create & connect, requirements complete. The phase the Servers screens had been waiting on since the first sync. Six ways to add a server (own cloud account · managed · existing server by root password · existing server by install command · connect an existing OSS panel · the free ServerAvatar Lite), the stack choice (LEMP, LAMP, OpenLiteSpeed, MERN — no Docker, no database at creation), five pre-create checks, live install progress with Retry / Delete, token handling, what Central stores, and an activity-log entry for who added which server and how. Pair 1 also removed Q1 and Q2 from its own open questions | New page FE: Add a server (+ nav). The two oldest questions on this site are answered: Q1 (stored fields, 8.11) and Q2 (how the token arrives, 8.10) — both moved to Answered, and both close to what this spec had recommended. Three things worth knowing. The stored OSS copy is one-time, at connect, so IP / OS / CPU / RAM / disk / app count can go stale — that is precisely why Q3 (offline display) is still open, and the backend explicitly parked "refreshing server data, offline status and needs-new-token". 8.7 confirms Bhavik's "no database-engine field" — the engine is installed on the panel afterwards. And new D-41: ServerAvatar Lite is a product with no Central account, so it has no screen anywhere and cannot be slotted into the wizard — flagged rather than invented. Also updated Servers (link record now "answered by 8.11"), FE: Integrations §B (its parked create-server draft is superseded), Missing backend, Phases and Open questions. The D-36 managed-server conflict is now written into two backend phases (6.9 and 8.2), so it is more visible, not less |
| 2026-10-06 05:40 | Both docs changed. Pair 2 (Phase 7) added system vs custom plans: the V7 tiers plus Managed / Self Managed, Legacy and Lifetime are seeded system plans with a fixed key that never changes; the admin can edit them but not delete them, Free cannot even be archived, and a custom plan is deletable only if nobody has ever been on it. Pair 1 (Phase 6) clarified that V7's "+3 per payment" belongs to a managed-server limit, not the plan's server limit — default 1, 10 for redeem-code signups, +3 per payment including auto-recharge, counting managed servers only, checked only for trial and cloud-hosting accounts | D-32 is refined, not reversed, and the two docs now agree — Pair 2 removed the bonus from the plan limit, Pair 1 named the counter it actually belongs to. The frontend conclusion is unchanged and worth stating plainly: because users cannot create managed servers (D-36), that limit is never reached from any screen, so the top-up success message stays "credit added" and the only limit a user meets is the plan's. Updated FE: Billing screens (6.4, 6.9), Servers and Open questions. For the plans change: added a system vs custom table to FE: Plans & subscription with the three distinct disabled states the admin list needs, extended the 7.19 archive row, noted it on Plans, and updated the flow doc's §18 Hide / Archive step. One judgement recorded: a fixed key now exists, but it is the backend's identity — the frontend still renders from data and does not branch on a key, with the single exception of showing it in the admin list |
| 2026-10-06 04:55 | Phase 10 marked complete, and a new 7.26. 7.26: when creating or editing a plan the admin can assign any available add-on to it (InsightHub / log monitoring, Object Cache Pro, and add-ons from later phases) and users on that plan get them included — but WP Toolkit and Premium Hosting Care are not assignable, and the downgrade check now also covers add-ons in use. Phase 10 went from "OSS part complete" to "requirements complete" with the note that Central simply uses the OSS API — and in doing so the backend removed its list of ten V7 features OSS does not have, parking them | 7.26 is good news twice over: the add-ons picker is just another API-driven list, and it confirms a rule this spec already had — Premium Hosting Care is shown to every user precisely because it can never be part of a plan. Added the 7.26 row to FE: Plans & subscription, extended the 7.8 downgrade reasons, and in the frontend doc updated §16 Add-ons (Status is no longer "not in the backend doc", plus an Included with your plan card state), §18 (an add-ons picker in the plan editor) and §14 (add-ons as a downgrade blocker). The parked list needs watching: FE: Application screens is now the only written record of all ten features — blueprints, app tags, restore to another server, backups of deleted servers, site migration, maintenance mode for all apps, Cloudflare DNS, temporary domains, "update app" for non-Docker apps and the Node Nginx / SSR port — so it carries a warning saying so, exactly as this site did for Q13 / Q14. D-39 (blueprints) is updated to "parked, unanswered" and Blueprints, Phases and Open questions say the same |
| 2026-10-05 12:38 | Phase 10 restructured half an hour after it appeared — the themed list of 18 features is now the OSS app panel tab by tab, 10.1–10.20, plus three Central-only rules 10.21–10.23. Renumbering aside, the real additions are: 10.2 Overview gained attention checks with fix buttons, a protection summary and first-run credentials shown once; 10.3 App actions is new (enable / disable, delete with an option to remove files and databases); the single "Security" feature split into four tabs (password protection, firewall, bot blocker, Fail2ban); Staging and Clone split; 10.21 plan limits puts app features in the plan feature list (Free starts without workers, app security, web firewall, separate database server, multiple domains per app); 10.22 gives every feature view / manage permissions; 10.23 adds an app activity log read from OSS. WP-CLI install disappeared (magic login survives in the Overview). The team-decision list grew from 8 to 10 (added backups of deleted servers and Node app Nginx config + SSR port, the V7 MERN case) | Rewrote FE: Application screens to the new numbering and noted what the rewrite dropped. Three findings worth keeping: the attention checks in 10.2 are a per-app version of the all-servers "Needs attention" screen, so the two should match rather than be designed twice; first-run credentials shown once is the other half of the no-secrets-in-email rule, which makes the panel the only place a user ever sees them; and 10.23 against 11.11 is a clean split — the app screen reads the OSS activity log while notifications deliberately do not, so the app history is complete and the notification feed is not. 10.21's "Free plan starts without…" is recorded as the admin's starting data, not a frontend constant. New D-40: mapping the backend's tabs onto the frontend doc's fixed app menu leaves four unplaced — Databases, Container & Compose, Settings and the app enable / disable / delete actions. Nothing was reordered, since the menu is Bhavik's decision |
| 2026-10-05 12:08 | New Phase 10 — Application panel features (10.1–10.18), requirements written, and 11.20 reversed again. Phase 10 is the phase that makes Central a hosting panel: create app (every V7 one-click app plus the OSS Docker apps, Git, custom PHP / static / Node), app list, domains with a DNS check, SSL with a dry run, a file manager with trash + restore, logs, PHP settings + isolation, app settings, environment (.env) with history, compare and restore, databases + one-click phpMyAdmin, Git deploy (key, deploy now, history, redeploy, deploy on push), backups (restore to the same server only), staging & clone, WordPress magic login, AI bot blocker / WAF / app Fail2ban, workers (Node apps are services now, not PM2), Docker apps and per-folder disk usage — all as Central screens calling the OSS API, with no app data in Central. It also lists 8 V7 features OSS does not have, waiting for the team's decision. Separately, Phase 9 — Server panel features became "prepared by Pair 1" (not published yet), and 11.20 now sends server / app / organization notifications to the organization owner only, as V7 | New page FE: Application screens (+ nav) covering all 18 features with the live-view consequences spelled out. Two corrections to this site: (1) 11.20 — an hour ago this site recorded "owner and members with access" as a change from V7; that is reversed, so the §"who gets a notification" section now says owner only and explains it rather than being quietly edited. (2) D-39 raised, and it is uncomfortable: WordPress blueprints is on Phase 10's undecided list, yet this site has a whole Blueprints page, a frontend-doc section and roadmap phase 9 for it — so that phase now carries "don't schedule until the decision lands", and D-14 / D-15 only matter if the answer is yes. Three more undecided items are already described here too (app tags, restore to another server, maintenance mode for all apps). Also new D-38: with owner-only notifications, a member who manages a server is never told when its backup or SSL renewal fails. Updated Server details (the app half now has a phase; the server half is Pair 1's and unpublished), Phases, Open questions |
| 2026-10-05 11:40 | Three things at once, and the backend doc was being rewritten while I worked. (1) Phase 9 → Phase 11: two empty phases were inserted — Phase 9 Server panel features and Phase 10 Application panel features, both "not prepared yet" — so Notification & Mail moved to Phase 11 and every item renumbered 9.x → 11.x. (2) New 11.21–11.23 and 11.3: email clean-up with no secrets in emails (2FA backup codes shown once on screen with a download, email only a notice; "DB root password changed" without the password), one email per family (managed-server credit 10 → ~4; plan reminders → one "expires soon" + one "expired"; auto-recharge + card → one "Billing settings changed"), old invoice "Payment received" dropped, one subject style naming the server, seven new V8 emails, plus a plain-text version and mobile-friendly layout. (3) Two complete V7 maps — all 90 emails and all 43 in-app notifications — each marked kept / changed / merged / moved / dropped, and 11.20 now says in-app notifications go to the owner and members with access (V7: owner only). Also decided: no flood limit, no digest, no reply-to support address | One real screen change, and it was a correction: this site and the frontend doc both offered "email backup codes" — that would now email a secret, so it is gone from FE: Account screens 3.8, the flow doc's 3B tab and the proposed admin "2FA help"; codes are shown once with copy and download. Renumbered 159 item references and 34 phase mentions across nine content pages and the flow doc (B9.x → B11.x), leaving the flow doc's own V8-9.x section numbers untouched. Added 11.21–11.23 rows, a V7 email map section and a "who sees an in-app notification" section to FE: Notifications & mail; recorded the never-email rule on Security; cleared a stale 3.17 note still claiming OSS has no alerts endpoint. The new empty phases are good news for Servers and Server details: the OSS-panel screens finally have backend phases reserved. Open question for the frontend: a member can now receive a notification about a server they cannot change, so those items must read sensibly without action buttons |
| 2026-10-05 11:05 | Phase 11 is now marked "Requirements complete" (it said "Requirements written"). One word, but it is the signal that the phase has settled — it had been changing every few minutes all morning | Updated the status wording on FE: Notifications & mail, Phases, Missing backend, this page's Phase 9 row and the frontend doc's §24 Status line. While there, swept out wording the 11.7 rework had left stale: nothing now describes a "settings matrix" (there are two screens), the admin screen list says check frequency rather than alert limits (those are the user's, per server), and the existing-users rows say migrated per-server links arrive with all six groups ticked |
| 2026-10-05 10:52 | 11.7 rewritten and the final event-group list published. Notification choices now live in two places: channels are attached per server (Server → Notifications, as V7) with six event-group ticks per attached channel — Alerts · Backups · Apps & deploys · SSL & domains · Databases · Server changes, all on by default — while the four account groups (Security, Billing, Plan, Organization) are not tied to a server and are chosen once in Account → Notification settings. The backend also published the complete group table with everything each group covers, and confirmed that migrated per-server links arrive with all groups ticked, so nothing changes for existing users | This overrode a design this site had proposed, so it is recorded rather than quietly swapped: we had specified one global events × channels matrix with per-server overrides; the backend chose two simpler screens. That also answers the "per-server settings at scale" question this spec had raised. Rewrote §C of FE: Notifications & mail (two screens, plus the full group table), realigned §B so nothing still describes a matrix, and updated Notifications — where the hand-written type list (server.offline, wallet.low_balance…) is now dropped, since every case falls inside a published group — and FE: Account screens 3.15, which now says channels are created there but used in two places. New question D-37: the backend says "Server → Notifications", but the frontend's server menu order is fixed and has no Notifications item — a placement decision for Bhavik, with the per-server alert limits (11.13) in the same boat |
| 2026-10-05 10:36 | Backend: one clarification. 11.3 firmed up — the email layout and texts are fixed in the code (translation keys) and are not editable from the admin panel for now. It used to read "fixed for now (admin editing later)", so the difference is that an admin template editor is now explicitly out | Sharpened the 11.3 row on FE: Notifications & mail: the admin mail screen is settings and logs only, with no room left in its layout for a template editor. Separately, applied Bhavik's 2026-10-05 10:24 decision that the default organization can never be deleted — the backend's Phase 4 already refused it, this makes it absolute. Updated FE: Organization & Members (4.2: the Delete button is permanently off on the default, not "make another one default first" — the default is created at sign-up, D-2, so delete only ever applies to extra organizations), Organizations (Phase 4 summary and the V7 delete row, where V7's "only organization" rule is now implied) and this page's 4.1–4.2 row. One accuracy fix in the frontend doc: the alert list now includes CPU and the top processes an alert carries (B11.13) |
| 2026-10-05 10:22 | Phase 11's server/app events were reworked, and it reverses two rules this site had recorded an hour earlier. 11.11 is now "actions done through Central": sent right after OSS answers, with long actions (deploy, restore, SSL request, add-on runs) followed by a background job and sent when they finish — and actions done directly in the OSS panel are explicitly NOT sent, with no activity-log reading and no OSS changes. 11.12 is new: scheduled checks of existing OSS APIs (backups every 15–30 min, SSL daily, auto-deploy every few minutes, metrics every 5 min, services, health), how often set by the admin, replacing V7's monitors. 11.13 is rewritten: Central reads live metrics every 5 min and compares them with limits the user sets per server (defaults CPU 100%, memory 80%, disk 90%, load 5 min = cores + 0.3, load 15 min = cores + 0.1), the alert carries the top processes, and load alerts fire at most once a day per server. New 11.20 spells out the send pipeline, including who gets an event (owner + members with access to that server / organization + the person who did it) and that required events always go by email | Two corrections, stated plainly rather than quietly overwritten. (1) This site said server events covered everything done in OSS "whether from Central or directly in the panel" — the opposite is now true, so the notification feed is not a full history of a server and no screen may imply it is. (2) It said alert limits were admin settings — they are the user's, per server, which adds a small per-server alert-limits form whose defaults depend on the server's core count. Both fixed on FE: Notifications & mail (§D rewritten, new 11.20 row), Notifications, Open questions (D-17's answer reworded — still answered, different mechanism) and Missing backend. Newly captured: the in-app list is permission-scoped, so never cached across users; the alert needs room for a top-processes table; and freshness is now partly published but the interval is an admin setting, so no screen states it. Frontend doc: §3C and §21 corrected, §24 admin screen changed from "alert limits" to check frequency |
| 2026-10-05 10:07 | Phase 11 sharpened, with one real security change. 11.15 rewritten — it was "follow-up emails as V7"; it is now credentials emails: when server / database / app credentials are created the email says "your credentials are ready — view them in the panel", and no passwords are emailed (V7 sent them in plain text). New 11.19 — security emails: password changed, new login from a new device / IP, API token created, all required. 11.11 now notes it replaces V7's own server checks (server monitor, load, service monitoring). And a list of V7 emails that stop in V8: old invoice-billing emails, the wallet negative-credit email, self-managed server reminders, and the follow-ups | 11.15 lands a requirement on the frontend: the email is only a pointer, so the panel must show credentials on demand and a once-shown generated password needs a retrieve-or-reset path — recorded on FE: Notifications & mail and Security. 11.19 adds three locked rows to the settings matrix, also noted on FE: Account screens against 3.5 (which now says security and billing emails can't be switched off, and that the screen is an arrival point from an unsubscribe link). The "emails that stop" list closes two loops: the wallet negative-credit email matches Pair 1's removed wallet track, and invoice emails going away matches Phase 6 saying receipt. Also applied two of Bhavik's standing decisions to this site: no language in the address (the last stale /{locale} mention is gone from Open questions; Routes and Internationalization already said it), and a default organization is created at sign-up — a Conflict with the backend's Phase 2, now flagged as D-2 on Organizations, FE: Auth screens, FE: Organization & Members, User journey and Phases, replacing the old "create your first organization" step with a fallback-only screen |
| 2026-10-05 09:37 | New Phase 11 — Notification & Mail (11.1–11.18), requirements written, plus Phase 8 — Servers noted as Pair 1's (a pointer, no rules yet). Phase 9 puts every email and notification in Central behind one system: admin SMTP settings + test email, background sending, a shared email layout whose texts use translation keys, a searchable sent log; one event list (key, group, default channels, required or not — security and billing can't be turned off) that each later phase adds to, and one sender that decides email / in-app / channel; the user picks events per channel and, for server and app events, per server; account, billing and plan events can now go to channels (V7 was server-only); a channel that keeps failing is marked "not working"; informative emails carry an unsubscribe link. Server and app events come from Central polling each server's OSS panel (activity log, metrics, services, health) — OSS does not push — covering every action done in OSS, success or failure, from Central or directly in the panel, plus alerts against admin-set limits, each sent once with a "back to normal". Also follow-up emails, the unverified reminder, admin announcements and Mautic sync | New page FE: Notifications & mail (+ nav): admin mail screens, the event-list matrix, per-server overrides, the failing-channel state, the OSS-polling consequences, and announcements. Answers D-17 — the oldest gap on this site: the [!MISSING] "OSS has no alerts API" warning on Notifications is replaced, and the answer is option (a) exactly as recommended, Central polling and raising its own alerts. Moves Q8 forward: emails use translation keys, though API errors still aren't typed — noted on Internationalization. Updated Notifications (the proposed type list is demoted to a checklist — the catalogue is now the backend's), Missing backend (notifications + alerts-source rows rewritten), Phases (phase 10 scope + D-17 struck), Open questions (D-17 moved to answered). Frontend doc: §3C rebuilt around the event matrix, §21 Needs attention aligned to the real alert rules, and a new §24 Admin: notifications & mail. Flagged as still open: how per-server settings scale, the unpublished poll interval, and Mautic consent |
| 2026-10-05 07:52 | Two rules changed, and both closed an open question. 6.4: V7's "+3 to the server limit per payment" is dropped — Pair 2's note says the server limit comes only from the plan (Phase 7). 7.12 rewritten: the expiry outcome now depends on the server type — at the warning day (default −7) managed servers are powered off at the provider, and at the lock day (default −15) managed servers are deleted at the provider while self-managed servers are only removed from Central and left running. (The 7.12 edit landed between the 07:32 diff and the 07:36 snapshot of the previous run, so it was picked up here from the backend's own change-log row.) The backend also compacted its change log from ~40 rows into three | D-31 answered: Pair 1's "power-off and deletion" and Pair 2's "removed from Central" were each describing one half, so nothing had to be unpicked — only made type-aware. The expiry banner now needs two dates (power-off, lock) and must name the servers and which fate is which; the locked screen may promise "still at your provider" only for self-managed servers. D-32 answered: the usage bar shows the plan's number with no bonus, and the top-up success message no longer claims the server allowance grew. Updated FE: Plans & subscription (7.12 + 7.22 rows, D-31 callout now a resolved note), FE: Billing screens (6.4 + redeem row, both "still open" bullets struck through), Servers (per-type expiry table + plan-limit row), Billing, Subscriptions, Missing backend, Phases, Open questions (D-31 and D-32 moved to answered). Frontend doc: §5.1, §7, §14, §15 |
| 2026-10-05 07:35 | Mirroring, no rule change. Pair 2 replaced their Phase 6 placeholder with Pair 1's full Phase 6 text (6.1–6.13, "not in this phase", existing users), copied word for word — the only edit is "(by Pair 1)" → "(from Pair 1)", verified by diffing the two sections. Their doc is now self-contained with Phases 1–7. Side effect: the short title "Billing, Wallet & Payment" they used for 40 minutes is gone, so both docs are back to one title — "Billing: wallet, payments & managed servers" | Reverted the short-lived name on Billing and FE: Billing screens, and updated this page's source table and Phase 6 row. Raised a staleness warning worth knowing: Pair 1 copied Phase 7 at 06:32, before Pair 2 rewrote 7.14 at 06:59, so Pair 1's 7.14 still shows the removed "Master / Business only" rule and the removed display name. The source table now says to read Pair 2's doc for Phase 7. No screen, flow or rule changed, so the frontend project doc was not touched |
| 2026-10-05 07:06 | 7.14 Plan visibility rewritten. All plans are now shown to all users — every new user sees the same common catalogue. A plan can still carry a list of users who may see it, but for one purpose only: V7 → V8 migration, where "restructured" V7 users get two plans of their own, "Managed" and "Self Managed", each with its own name, price and features, and see only those. The backend explicitly removed the old "Master / Business only for allowed users" rule and the per-plan display name | Two earlier assumptions corrected. The display name is gone: this spec had told the frontend to prefer display_name over the name to cope with V7's "Newbie shown as Managed" trick — those are now real plans with real names, so the frontend shows name and nothing else. Removed from Plans (catalogue fields, the formatting rule, the V7 tiers row, eligibility) and the admin editor in the Frontend project doc §18. Visibility is no longer a general feature: the plans page is the same for everyone by default, but the catalogue is still never cached across accounts, because a migrated user legitimately sees a shorter list. Updated FE: Plans & subscription (7.14 row rewritten + a new existing-users row for restructured accounts), V7 migration (new row), Missing backend, and this page's 7.1/7.2/7.13/7.14 row. No new conflict or open question |
| 2026-10-05 06:50 | Naming only, no rule change. Pair 2's Phase 6 placeholder got a title — "Phase 6 — Billing, Wallet & Payment (by Pair 1)" — and its status line now adds that "Phase 7 plans are paid from the credit balance managed here", which this spec already said. Note the two docs use different titles for the same phase: Pair 1 calls it "Billing: wallet, payments & managed servers" | Took the official name on Billing and FE: Billing screens, noting Pair 1's own title so neither looks wrong, and updated this page's source table and Phase 6 row. No screen, flow or rule changed, so the frontend project doc was not touched |
| 2026-10-05 06:35 | Pair 1 only. They copied Pair 2's whole Phase 7 (7.1–7.25) word for word, so both backend docs now carry Phases 1–7 — no new product rule from that, just a second copy. Their internal pointers were retargeted from "Plans & subscriptions phase" to "Phase 7 — Plans". 6.12 was reworded step by step and the expire-date sentence now leads with the deletion: servers with no apps and no databases are deleted, the others are powered off. 6.13 gained real new rules: going back above 0 stops the process and clears the saved dates, a trial account leaves trial mode, and powered-off servers are not powered on automatically (all as in V7) | FE: Billing screens: 6.12 and 6.13 rewritten. The 6.13 detail answers a hedge this spec had been carrying — it said powered-off servers "do not necessarily come back by themselves"; now it is a rule, so the top-up success message must not imply a restored server, the banner and deletion dates must disappear, and the plan and limits must be re-read because trial mode ends. Servers, Billing updated to match. Separately, Bhavik's 2026-10-05 06:19 decision that users cannot create managed servers was only recorded in the flow doc, so it is now flagged on this site as new Conflict D-36: backend 6.9 specifies the creation flow, the frontend builds no screen for it, and everything about existing managed servers stays. Updated Open questions, FE: Billing screens §D, Servers, and the source-documents table (Pair 1 now carries Phase 7) |
| 2026-10-05 06:24 | Pair 1 cut a whole track out of Phase 6, and refined what is left. The wallet negative-balance track (plan-billed servers, days 1/3/5, 7/11/13, day 15 deletion, "backups / SSL / health checks stop") is removed — "that V7 code is no longer scheduled". Unpaid plans now belong entirely to the plan expiry flow in Phase 7, along with the support pack, and Phase 6's negative balance covers managed servers only, renumbered 6.12–6.13. The surviving process was then sharpened: on the expire date, servers with apps or databases are powered off while servers with none are deleted that day — Central asks each server's OSS panel which it is — and the rest are deleted on the deletion date. The timing days (+4 / +3 / +7, trial 2 / 2 / 4) are confirmed as V7 defaults that an admin will later manage from settings, in its own phase. Pair 2, in parallel: the plan expiry day numbers are admin-set too — reminder start (default 7 days before), warning day (default −7), lock day (default −15) — and auto-renew retries until the lock day rather than a fixed day 15 | Conflict D-31 shrank and was rewritten: the "day 15 twice" clash is gone, leaving only a wording difference between the docs (Pair 1 calls the plan flow "power-off and deletion of a plan's servers"; 7.12 says "removed from Central, not deleted at the provider") — the frontend follows 7.12 and flags it. FE: Billing screens: §E rewritten as one track, renumbered, with the expire-date split and a warning box about the removed scope; the old conflict callout deleted. FE: Plans & subscription: new admin row for the four timing settings, 7.10 / 7.11 / 7.12 reworded around admin-set days, D-31 callout rewritten. Billing, Servers (the "paused by billing" state is gone; the two-kinds table now points at 7.12 vs 6.12), Dashboard, Subscriptions, Phases, Missing backend (negative-balance row narrowed + new timing-settings row), Open questions (D-31 rewritten, new D-35: what happens on the expire date when a panel is unreachable). Frontend doc: §5.1 wallet row replaced, §7 "paused by billing" step removed and the managed-server deletion split added, §14 and §18 day numbers now dates. New hard rule recorded everywhere: no expiry day count in any screen or translation string — always the API's date |
| 2026-10-05 06:07 | Phase 7 refined: the expiry story is now fully written, plus new 7.25. 7.25 Expiry date — a plan keeps a real expiry date instead of V7's day counter, has a status (active / expired / locked) and is checked on every action, so a missed nightly job can't keep an expired plan working; V7's counter becomes a date at migration. 7.10 auto-renew now retries every day until day −15, so the plan renews as soon as credit is added. 7.11 the admin picks the reminder weekdays (default Mon + Thu). 7.12 gains what an expired user can still do: view data, delete a server, add credit / renew — everything else refused with "Plan has expired. Please renew it" | FE: Plans & subscription: new 7.25 row, rewritten 7.10 / 7.11 / 7.12, and the existing-users row (counter → date). Subscriptions: the "V8 should expose an explicit status" gap is closed — new callout, expired state rewritten, expiry-and-renewal bullets re-badged V7 only → V8 requirement. Servers: the plan-expired rule is now V8 requirement — pages stay readable, only Delete server and Add credit survive. Plans, V7 migration, Missing backend (subscription row: rules written, endpoints still missing). Frontend doc: §5.1 Expired and Locked rows, §14 steps 1 and 7, §7 server-page step 8, §18 step 10. No new conflict and no new open question — this batch only turned earlier guesses into written rules |
| 2026-10-05 05:42 | Phase 7 extended again, minutes later: 7.23 and 7.24. 7.2 now carries the API rate limit per minute as a plan feature (V7 values Free 60 … Business 180 as starting data); 7.7 requires an upgrade preview before paying (credit back, amount to pay, new end date); 7.23 Redeem codes — the admin creates batches of codes giving a plan or credit (quantity, expiry, on / off, download the list, see who used each code), users redeem from their account and each code works once; 7.24 Admin plan overview — users per plan, upcoming renewals, accounts close to being locked. Referral rewards and plan-included add-ons stay parked for their own phases | FE: Plans & subscription: rows for 7.2 (rate limit), 7.7 (preview), 7.23 user and admin sides, 7.24; new plans.redeem.* namespace. The redeem dialog must say what a code gives before confirming and has five distinct refusal messages. FE: Billing screens: a credit code is not a payment — no gateway, no tax, no receipt, no "+3 servers" — and gets its own wallet-history row kind. Plans: rate limit is now a plan feature, the preview's contents are fixed, redeem data added. Frontend project doc: §14 step 3 (new end date) and step 10 (Redeem code), §15 step 2 (redeem from the wallet), §18 steps 7–8 (code batches, plan overview) |
| 2026-10-05 05:38 | Phase 7 grew from 7.17 to 7.22. Changed: 7.6 a trial now ends in a must-buy gate ("must pick a paid plan to continue"); 7.12 the owner's team members are locked too at day −15. New: 7.18 turning a feature off or lowering a limit warns users first and applies at their next renewal; 7.19 users on an archived plan keep it until they change, new users can't pick it; 7.20 the admin can give one user their own plan (custom price, server / app limits, cycle, expiry days); 7.21 the admin can mark a user free forever; 7.22 a locked account unlocks automatically once the user adds credit and pays, and servers removed at day −15 stay removed. Also: lifetime installments (V7's 1-or-3 payments) parked with the lifetime decision, and — missed by the 05:01 snapshot — plan names are not final and renameable, with users on a renamed plan keeping the same plan | FE: Plans & subscription: rows for 7.1a, 7.18–7.22 and rewritten 7.6 and 7.12; the trial-end gate as a third blocking state next to expired and locked; a members' version of the locked screen (no billing tab, no pay button, names the owner); a pending-change note for price and limit changes; and the rule that the current plan is never looked up in the catalogue (it can be archived or user-specific). Updated Plans (two new callouts, renameable names, trial gate), Subscriptions (new trial_ended, free_forever and locked states, unlock rule), Members (locked with the owner; plans can switch the team-members feature off), V7 migration (installments, free forever, per-user plans), Missing backend (catalogue must carry archived + pending-change; new admin per-user-plan row), Open questions (new D-33 Free after a trial, new D-34 admin lowering a limit below current usage; D-4 notes installments). Frontend project doc: §5.1 trial-ended / free-forever / member-locked rows, §5.5, §14 steps 6b–6c and 8, §18 steps 2c–2d and 5 |
| 2026-10-05 04:51 | New Phase 6 — Billing: wallet, payments & managed servers, requirements complete (6.1–6.14, Pair 1): Stripe / PayPal / Instamojo each with on/off + test/live and only enabled ones shown; billing details on the account that pays, copied onto every receipt; wallet of paid / free / promo credits with V7's server credits dropped (leftover → paid credits at migration); top-up with a settings minimum, $4,000 maximum, promo codes (not at or below the minimum), tax as V7, credit added only after the gateway confirms and credited once, and +3 to the server limit per successful payment; Stripe saved card + auto-recharge; low-credit reminder $1–$1,000; payments-and-charges history with a receipt per payment; managed servers charged hourly from paid credits only against an admin price list (DigitalOcean, Vultr, Linode, Hetzner); and negative balance as one process with two separate tracks (A wallet: day 15 plan-billed servers deleted, backups / SSL / health checks stop · B managed: due +4 d → powered off +3 d → deleted +7 d, trial 2 / 2 / 4) | New page FE: Billing screens (+ nav): gateway-driven Add credit with the "Confirming payment…" return page, three wallet balances, cards + auto-recharge with the "Add a card first" block, history with receipts only on payment rows, the managed-server create check and usage screens, and two separate overdue banners instead of one. Updated Billing (Phase 6 rules, D-5 closed, gateways section rewritten, receipts replace invoices), Servers (a second kind of server + billing states + the +3 limit), Providers (managed price list covers four providers, no Lightsail), Subscriptions, Dashboard, V7 migration (server credits → paid credits, cards and managed servers carry over), Phases, Missing backend (billing + managed servers + negative balance rows), Open questions (D-5 answered and moved, D-4 completed, D-22 sharpened, new D-31 and D-32). Frontend project doc: §15 rebuilt as 6.1–6.14 steps, §5.1 negative-balance rows, §7 managed-server path, §1.2 |
| 2026-10-05 04:51 | Phase 7: new 7.17 Price change — when the admin changes a plan's price, users already on that plan get a warning email first and the new price starts at their next renewal | FE: Plans & subscription: new 7.17 row (show the price that will be charged next, old price struck through, renew-shortfall warning recalculated) and 7.10 updated. Plans: a note that an edited price reaches existing users at renewal. Frontend project doc: §14 step 6a and §18 step 3 — the admin editor's old "new buyers only / everyone at renewal" choice is now marked as a frontend proposal, with at renewal as the backend's rule |
| 2026-10-03 12:35 | New Phase 7 — Plans (Subscription), requirements complete (7.1–7.16): plans are dynamic, created by the admin with a feature list on / off per plan; one plan per owner across all their organizations; paid from credit with tax added; trial; plan change returns unused days as credit; downgrade blocked when usage or a feature in use doesn't fit; cancel / resume; auto-renew from credit; reminders; the V7 expiry flow (day −7 warning → day −15 servers removed from Central, account locked); coupons; per-plan visibility and display name; enterprise form; activity log. Existing users keep their plan, lifetime and legacy per-server plans. Phase 6 is Pair 1's (no rules yet) | New page FE: Plans & subscription (+ nav): admin plan editor, plan page, confirm-and-pay from credit, downgrade blocking, expiry banners, locked-account screen, enterprise form, and a shared "may I do this?" pattern for plan / limit / permission refusals. Updated Plans, Subscriptions (D-3 answered: the owner), Billing (D-4 answered: credit wallet stays), Audit log, Phases, Missing backend, Open questions (D-3, D-4, D-6 answered and moved; D-5 and D-22 sharpened). Frontend project doc: §14 (owner-level plan, unused days as credit, coupon field, downgrade block, expiry countdown, locked page, enterprise), §18 (feature list, visibility, coupons), §5.1 and §5.3 |
| 2026-10-03 11:35 | Pair 1 copied Pair 2's finished Phase 5 into their doc, word for word (providers in Central, Git and storage in each server's OSS, named accounts, Edit, Test, per-server results, activity log, who-can-do-it, existing users). No new product rule, so no screen changes | Updated the source-document table (both docs now carry the same Phase 1–5 rules) and this change log. Worth noting for D-27: both backend docs now say cloud providers are organization level, while the frontend doc keeps them at account level — so that difference needs a decision rather than drifting |
| 2026-10-03 11:05 | 5.16 Activity log added: every integration action is recorded in the organization activity log (who, which account, which servers, when) and tokens / keys are never logged. 5.13 clarified: the same account on several servers is shown once even when each server holds a different token | FE: Integrations: new 5.16 row (one entry can span several servers), 5.13 reworded. Audit log: the organization log now also carries integration actions. Frontend project doc: 3.I3 / 3.B5 ("even when each server has its own token/keys"), 3.I4 / 3.B4 (replace-token modal lists the servers it will overwrite, each untickable), 3.B6 (actions appear in the activity log, never the keys). New question D-30: a row can hide different per-server tokens, yet "update everywhere" replaces them all |
| 2026-10-03 10:50 | Phase 5 polished and renumbered. Provider accounts get a name and several per provider are allowed; new 5.3 Edit (rename or re-token) which "Needs new token" now points to; Git / storage accounts get a name too; the per-server result covers connect, update and remove; new 5.9 Test per server; new "Who can do it" — connect, edit, test and remove follow the organization roles; old 5.16 renumbered to 5.13. Existing users: DigitalOcean and Linode must paste a token once after the move, the others move as they are. The backend also deleted their "Not in this phase" list, open points Q9–Q14 and the parked create-server draft | FE: Integrations retabled to the new numbering (name fields, Edit, Test, result-per-server for all three actions, "Who can do it", 5.13), plus a warning that our site is now the only written record of the removed points — including the Q13 security hole. Providers: named accounts, several per provider, no duplicate-by-email rule, D-29 answered. Open questions: D-29 moved to answered, Q13/Q14 marked as kept-here-only. Missing backend. Frontend project doc: 3.I1 (name, Edit, several accounts, migrated DO/Linode), 3.I2 (name, Test), 3.I4 and 3.B6 (result per server, role-driven buttons) |
| 2026-10-03 10:35 | 5.16 added: Central reads Git / storage accounts that already exist on a server's OSS panel and shows them, the same account only once across servers, with the token pasted once to extend it to more servers. Also picked up 5.5: disconnecting a cloud provider is blocked while any server was created with it (the warning lists them) | FE: Integrations: new 5.16 row (found-on-server accounts, grouped by account, marked, no pretend secret), rewritten 5.5 row (disabled button with "Used by N servers"), plus a line explaining that the account — not the server — is what users manage. Providers: our earlier "refuse disconnect while servers exist" recommendation is now confirmed by the backend. Frontend project doc: 3.I1 disconnect and new 3.I3a |
| 2026-10-03 10:20 | Phase 5 requirements complete. Connecting is now token-only: Vultr, DigitalOcean, Linode and Hetzner take a pasted API token, Lightsail an access key + secret — no OAuth login and no automatic renewal; a rejected token marks the account "Needs new token" (5.2, 5.4). 5.3 regions & sizes moved to the Servers phase, 5.13 repos & branches moved to the Applications phase. Q9 accepted (tokens / service account instead of one-click login), Q10 parked for the migration phase, Q11 Dropbox skipped for now | FE: Integrations: one connect modal for every provider, "Needs new token" state, 5.3 and 5.13 removed with pointers, Q9–Q11 resolved, Dropbox noted as unsupported. Providers: Conflict callout — V8 drops the V7 OAuth login, so no redirect screen, no duplicate-by-email rule and no refresh middleware; regions & sizes marked moved. Phases, Missing backend, Open questions (Q9/Q11 answered, Q10 parked, new D-29), frontend project doc 3.I1 and 3.I3 |
| 2026-10-03 10:05 | Phase 5 narrowed: creating a server at a cloud provider and the automatic OSS install moved out to the Servers phase (draft parked at the end of Phase 5 with Q13, Q14, the Ubuntu 20.04 limit and Hostinger's pre-installed Apache/MySQL). Q12 answered: Hostinger is not a provider — V7 only detects a Hostinger IP when adding an existing server. 5.3 regions & sizes stay in Phase 5 and are used by the Servers phase | Re-scoped FE: Integrations (§B marked as Servers-phase work, nothing deleted), Providers (create-VPS section marked moved, Hostinger answer), Servers (now owns create-server, plus the Ubuntu 20.04 and Hostinger notes), Phases (create-server from phase 8 → phase 5), Missing backend (split into "cloud providers" and "create server", Q13 marked P0 security), Open questions (Q12 answered and moved, Q13/Q14 re-scoped). Also raised the Conflict for D-27 (account-level vs organization-level integrations) on the spec pages, and renumbered my role-migration question to D-28 because D-26 is now Bhavik's auth-flow decision |
| 2026-10-03 09:50 | Phase 4 — Organization & Members completed by Pair 1 (4.1–4.8): default organization + letter avatar, delete rules, invites that must be accepted with 7-day links, one role per member, fixed Owner/Admin + custom view / manage roles with auto-ticked parents, no deleting a role in use, share one server, new ownership transfer (both sides confirm with own password + 2FA, 48 h, old owner → admin), organization activity log | New page FE: Organization & Members (+ nav). Updated Organizations, Members, Roles & permissions, Audit log, Phases, Missing backend, FE: Integrations + Providers (their Phase 4 dependency is satisfied), and the frontend project doc (4.1–4.8, 12.3–12.5, 13.4–13.5). D-7, D-8, D-9 and D-25 answered and moved; two Conflict callouts raised (sharing stays; one role per member) and one new question D-26 |
| 2026-10-03 09:35 | Phase 5 — Integrations drafted (Pair 2). "Option B": cloud providers stored in Central at organization level; Git accounts and backup storage live in each server's OSS and Central keeps only a note; create a server on a provider with automatic OSS install through a start-up script; organization Integrations page; open points Q9–Q14 | New page FE: Integrations (+ nav): provider screens, create-server wizard and live progress, Git / storage modals with "add to other or all servers" and per-server results. Updated Providers (Phase 5 rules, D-12 answered, Q13/Q14 warning), Servers, Server details, Phases (phase 8 renamed Integrations, could move earlier), Missing backend, Open questions (D-12 answered and moved, D-13 deferred, Q9–Q14 added), frontend project doc (4.6 Integrations, 6.2/6.2a/6.2b create-server, 7.5–7.6 Git, Backups → Storage) |
| 2026-10-03 08:20 | Pair 1's doc caught up with Pair 2's — it now contains the same rules (Phase 3 Account, Phase 4 + Phase 5 placeholders, Passport/per-pair-database conventions, OSS client with the Servers phase, Q7–Q8). No new product rule, so no screen changes | Updated the source-document table (Pair 1 is no longer a subset) and D-25: Pair 1's Phase 4 section now exists as "requirements in progress", so we know where those rules will be published. Also noted on Organizations, Members, Phases |
| 2026-10-03 07:20 | Phase 3 3.15: Discord and Webhook added as notification channels (V7 already had both, so migrated channels keep working) | Added both types to the channel type picker and per-type fields: FE Account screens (3.15, layers diagram), Notifications, V7 migration, frontend project doc 3.15 |
| 2026-10-03 07:20 | Phase 3 3.13 + existing users: V7 API tokens are migrated and keep working; users do not create new ones | API screen is a switch with no "create token" button — closes the old Open question about a copy dialog. Updated FE Account screens (3.13, existing users), V7 migration (new API-tokens row), frontend project doc 3.13 |
| 2026-10-03 07:20 | 2.9: Central issues the access + refresh token itself after password → 2FA → IP checks, for email and Google/GitHub login; method decided in the backend's Phase 2 plan | D-1 is now partly answered: no browser-side OAuth grant. Updated FE: Auth screens 2.9, FE: Foundation 1.4 + D-1 note, Open questions D-1 |
| 2026-10-03 07:20 | §2.2: the common OSS API client moves from the Foundation phase to the Servers phase | Updated Architecture, Missing backend; the frontend roadmap already put Server Details in phase 5, so no re-ordering was needed |
| 2026-10-03 07:20 | New Phase 4 — Organization & Members (by Pair 1) and Phase 5 — Integrations (requirements in progress) | Flagged a new gap D-25: Phase 4's rules are in neither published doc. Updated Organizations, Members, Providers, Phases, D-20 |
| 2026-10-03 07:20 | Q7 PHPStan skipped for now; new Q8 — nobody owns i18n setup yet | Recorded in Open questions (Q7, Q8) and a warning on Internationalization with what the frontend needs from the backend |
| 2026-10-03 | Initial sync against the Pair 2 doc as of 2026-10-01 11:55 (R1–R7, Phases 1–3, Q1–Q3, Q7) | Added FE Foundation, FE Auth screens (2.1–2.11), FE Account screens (3.1–3.17), this traceability page |
| 2026-10-03 | — | New standalone Frontend project doc (/frontend/) mirroring the backend doc's structure: rules, architecture, code standards, working method, Phases 1–3 screens, FE-Q1–FE-Q8 |
| 2026-10-03 | — | Frontend project doc trimmed to frontend-only items (screens 2.1–2.11, 3.1–3.17, app foundation, screen states). Backend rules and open questions stay on this site |