[platform] Roadmap audit + issue triage: apply the platform/service taxonomy, close stale, write the phased roadmap #283

New issue

Closed

opened 2026-06-14 03:22:03 +00:00 by mik-tf · 1 comment

mik-tf commented

2026-06-14 03:22:03 +00:00

Owner

Goal: do a full audit and triage of this tracker and produce one clean, phased roadmap organised by the new work-type taxonomy (see the repo README). The current board understates how much is already done, so planning against it is misleading. Close what is done, rewrite what is muddy, label everything consistently.

The taxonomy (now in the README)

Audiences: external testers (the sandbox deployment), internal users (staff dogfood), and a future paid/sovereign tier. "Sandbox" is the platform deployed for external testers, not a kind of work.
Work-types (labels): platform (the integrated stack and everything that runs it: deployer, onboarding, gateway, admin/cockpit, assembly, build/bootstrap tooling) vs service (a feature/bug inside one app).
Anything private or internal (the internal-user fleet, its funding, ops runbooks, company-private plans) is handled privately, outside this public tracker, never here.

Method: one pass over every open issue

Label each platform or service.
Fix the title prefix to name the area/service: [deployer], [hero_slides], [lab], etc.
Set/confirm the assignee (the owner). Platform work is coordinated centrally; service work sits with that service's developer. We track service work here; we do not implement it.
Decide its state and act:
- DONE then close (cross-check against the Sandbox Review recap and the code).
- DUPLICATE then merge into the canonical one.
- UNCLEAR then ask for a one-line restatement or a retest, or close if obsolete.
- OPEN/active then keep, labelled + assigned, slotted into a phase.
- Architecture/refactor metas then group as a separate long-horizon track.
- BLOCKED (external dependency: ThreeFold, or a specific person) then mark blocked with the dependency named.

Deliverable

One phased roadmap, split by platform vs service, each phase showing what is ours to build, what we are tracking the developers on, and what is blocked. Decide where it lives (refresh the meta arc #239 or the project board) rather than creating a third place.

Known starting corrections (confirm + apply)

"Mass update across all testers in one click" is already shipped (the admin has an Update-all-testers action that loops every tester VM, plus a per-user Update-all). The review recap still marks it open; correct/close it.
Several review-recap rows are DONE or need a retest; fold those in.
Speeding up the installer is a marginal lever. The real fast-onboarding answer for external testers is a pre-warmed pool (claim then set the gateway + sign-in), which also removes the fresh-machine network-route delay. Re-prioritise accordingly.

Out of scope

Building or fixing the apps themselves (developers' work; tracked here, not done here).
Anything private/internal (handled privately, outside this public tracker).

This is a high-effort, read-heavy synthesis pass; treat it as its own session.

Goal: do a full audit and triage of this tracker and produce one clean, phased roadmap organised by the new work-type taxonomy (see the repo [README](https://forge.ourworld.tf/lhumina_code/home/src/branch/main/README.md)). The current board understates how much is already done, so planning against it is misleading. Close what is done, rewrite what is muddy, label everything consistently. ## The taxonomy (now in the README) - **Audiences:** external testers (the sandbox deployment), internal users (staff dogfood), and a future paid/sovereign tier. "Sandbox" is the platform deployed for external testers, not a kind of work. - **Work-types (labels):** `platform` (the integrated stack and everything that runs it: deployer, onboarding, gateway, admin/cockpit, assembly, build/bootstrap tooling) vs `service` (a feature/bug inside one app). - **Anything private or internal** (the internal-user fleet, its funding, ops runbooks, company-private plans) is handled privately, outside this public tracker, never here. ## Method: one pass over every open issue 1. Label each `platform` or `service`. 2. Fix the title prefix to name the area/service: `[deployer]`, `[hero_slides]`, `[lab]`, etc. 3. Set/confirm the assignee (the owner). Platform work is coordinated centrally; service work sits with that service's developer. We track service work here; we do not implement it. 4. Decide its state and act: - DONE then close (cross-check against the [Sandbox Review recap](https://forge.ourworld.tf/lhumina_code/home/issues/275) and the code). - DUPLICATE then merge into the canonical one. - UNCLEAR then ask for a one-line restatement or a retest, or close if obsolete. - OPEN/active then keep, labelled + assigned, slotted into a phase. - Architecture/refactor metas then group as a separate long-horizon track. - BLOCKED (external dependency: ThreeFold, or a specific person) then mark blocked with the dependency named. ## Deliverable One phased roadmap, split by `platform` vs `service`, each phase showing what is ours to build, what we are tracking the developers on, and what is blocked. Decide where it lives (refresh the meta arc [#239](https://forge.ourworld.tf/lhumina_code/home/issues/239) or the project board) rather than creating a third place. ## Known starting corrections (confirm + apply) - "Mass update across all testers in one click" is already shipped (the admin has an Update-all-testers action that loops every tester VM, plus a per-user Update-all). The review recap still marks it open; correct/close it. - Several review-recap rows are DONE or need a retest; fold those in. - Speeding up the installer is a marginal lever. The real fast-onboarding answer for external testers is a pre-warmed pool (claim then set the gateway + sign-in), which also removes the fresh-machine network-route delay. Re-prioritise accordingly. ## Out of scope - Building or fixing the apps themselves (developers' work; tracked here, not done here). - Anything private/internal (handled privately, outside this public tracker). This is a high-effort, read-heavy synthesis pass; treat it as its own session.

mik-tf added the

platform

label

2026-06-14 03:22:03 +00:00

mik-tf commented

2026-06-14 03:28:56 +00:00

Author

Owner

Closing here. Roadmap and planning are coordinated privately; this public tracker holds the platform/service work items. The audit will relabel/triage the issues in place.

mik-tf closed this issue

2026-06-14 03:28:56 +00:00