Home-Network/home-network-k3s
2
0 Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
feature/vulnerability-visibility
home-network-k3s/roadmap/workstreams.md
T
jakman85andClaude Opus 5.5 18f7ba8d0f docs: apply the operator's rulings on Kasm, revocation and fault injection 
Retire Kasm from the catalog. Drop ACME revocation from R-TLS-02. Make L3
fault injection operator-run and exclude it from the merge gate (R-TEST-03,
ADR-0026). Update the gap register to match; Homepage authentication is now
ruled must-enforce and stays a gap until the implementation lands.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-11-08 23:06:26 -06:00

5.8 KiB
Raw Permalink Blame History

Roadmap — Workstreams

A workstream is a durable area of ownership. Each maps to an agent role (../agents/roles.md), owns a set of specs, exposes interfaces other workstreams depend on, and delivers against requirement IDs. Interfaces are contracts — change them only via ../agents/coordination-protocol.md.

ID Workstream Owns (specs) Serves Depends on
WS-INFRA Infra & cluster bring-up 02 R-PLAT-01, R-ENV-* —
WS-GITOPS GitOps, CI, catalog renderer, image pipeline, PM agent 05, 13 R-GITOPS-*, R-UPD-02 WS-INFRA
WS-NET Networking, isolation, egress, ingress 03, 09 R-NET-, R-DNS- WS-INFRA
WS-STORAGE Storage, state, backup/DR 04 R-STATE-* WS-INFRA
WS-SEC Secrets, TLS, RBAC, identity/SSO, auditability 07, 08, 15 R-SEC-, R-TLS-, R-IDP-* WS-INFRA, WS-NET
WS-OBS Observability & alerting 10 R-OBS-* WS-INFRA, WS-STORAGE
WS-UPDATE Automated updates 11 R-UPD-* WS-GITOPS, WS-OBS
WS-VM KubeVirt IaaS 06 R-PLAT-03 WS-NET, WS-STORAGE
WS-APPS Service onboarding 13 app requirements WS-GITOPS, WS-NET, WS-STORAGE, WS-SEC, WS-OBS
WS-C2 Command & Control UI 12 R-C2-* WS-OBS, WS-APPS, WS-SEC
WS-TEST Conformance testing (cross-cutting) 14 R-TEST-* WS-INFRA, WS-GITOPS

Key interfaces (contracts between workstreams)

  • ServiceDefinition schema (WS-GITOPS owns) — the operator surface every app/VM is expressed in. WS-APPS, WS-VM consume it; WS-NET/STORAGE/SEC/OBS render pieces of it. The most important contract in the system.
  • Network baseline & policy rendering (WS-NET) — default-deny + how dependencies and egress compile to CiliumNetworkPolicies/egress routing. Consumed by WS-APPS/WS-VM.
  • StorageClasses (WS-STORAGE) — the longhorn family (replicated, including static and VM variants) and bulk (media, NFS). Consumed by everyone with state.
  • Issuer + Gateway TLS (WS-SEC + WS-NET) — wildcard cert + Gateway listeners that HTTPRoutes attach to.
  • Observability contract (WS-OBS) — how a service declares metrics/SLIs/alerts and gets dashboards. Consumed by WS-APPS/WS-VM.
  • Update policy contract (WS-UPDATE) — the Renovate conventions a ServiceDefinition's update block maps to.
  • SSO/auth contract (WS-SEC) — how a ServiceDefinition's auth block (oidc / forward-auth / native / groups) maps to a Keycloak client or oauth2-proxy protection (15). Consumed by WS-APPS/WS-C2.
  • Conformance harness + gate (WS-TEST) — the reproducible test framework (Kyverno for L0 policy, Chainsaw for L1/L2/L3 behavior + fault-injection, ADR-0011), requirement-coverage report, and CI/phase gates every workstream's tests plug into. Each workstream authors its own behavior tests against this harness (14).

Parallelization guidance

  • WS-TEST stands up the conformance harness early (Phase 0–1) so every other workstream lands with passing, reproducible tests from day one — testing is not a trailing phase.
  • After WS-INFRA delivers a cluster + Flux (Phase 1), WS-NET, WS-STORAGE, WS-SEC can proceed largely in parallel (Phase 2).
  • WS-OBS, WS-UPDATE, WS-VM layer on next (Phases 3–5), overlapping.
  • WS-APPS is gated on the platform contracts being stable; onboard services in the dependency order below.
  • WS-C2 is last-ish (Phase 6) since it aggregates everything.

WS-APPS onboarding order (respect dependencies from 13)

  1. pihole (DNS underpinning) →
  2. gitea — bootstrapping-critical; brought online early so the platform self-hosts its git and CI/CD; after it is stable, WS-GITOPS cuts Flux's source over to Gitea and moves CI to Gitea Actions (../docs/05-gitops-and-delivery.md, ../CONTRIBUTING.md). DR-critical → off-cluster backup + mirror. →
  3. keycloak (+ oauth2-proxy) — foundational IdP/SSO, brought online early so later services integrate SSO as they onboard (../docs/15-identity-and-access.md). DR-critical + break-glass path. →
  4. plex (largest; validates bulk tier + L4 remote access) →
  5. qbittorrent, jackett (VPN + kill-switch proof) → 6. sonarr, radarr (VPN + arr↔downloader allows) → 7. seerr (cross-service allows to arr + plex) → 8. nextcloud (DR-critical data + backups) → 9. minecraft (delivered as Crafty, platform-managed), unifi (a KubeVirt VM), semaphore.

As each service onboards, it adopts SSO per its auth mode (native OIDC or forward-auth) — ../docs/15-identity-and-access.md.

GitOps source (WS-GITOPS, tied to step 2): Flux follows the self-hosted, in-cluster Gitea; CI (Kyverno gate + Chainsaw conformance Job trigger) runs on Gitea Actions; PRs are the enforced merge gate into main.

Each onboarding is a full acceptance-gate pass (../agents/definition-of-done.md), not just a merged manifest.

Reference in new issue View Git Blame Copy Permalink