Target Readiness Registry

Single source of truth for which targets (per specs/variants/taxonomy.kmd) the Koder Stack actually ships to today, versus those that remain canonical but inactive pending an external precondition (hardware, toolchain, partner agreement).

Every component that declares a target in koder.toml [app] platforms, every CI workflow that gates a build on a target, and every release engineering gate consults this registry. Flipping a target from inactive → active is a deliberate, owner-ratified change that must be reflected here before any consumer surface is wired.

This complements (does not replace):

  • specs/variants/taxonomy.kmd — the canonical enumeration of legal targets
  • policies/self-hosted-first.kmd — the 5-gate model for self-hosted

    components (overlaps with this registry only at G5)

  • registries/koder-id-auth-coverage.md — per-component per-surface

    conformance grid (surface definitions S2/S3 etc. remain descriptive regardless of target readiness)

Status values

Status Meaning
active Build, release, and deploy are exercised on every shipping wave.
inactive Target is canonical (legal in specs/variants/taxonomy.kmd, may appear in component koder.toml [app] platforms) but no shipping wave currently produces artifacts for it. CI jobs targeting it MUST be gated (if: false, runs-on: never, etc.) with a comment quoting this registry row.
experimental Build path exists but artifacts are not promoted to releases; smoke tests only.

Registry

Target Status Since Gating condition (if inactive) Notes
linux active always — Primary target. Every component that declares Linux must ship artifacts.
windows active 2026-04 — Built on Linux via cross-compile (Go) or WinRM → k.win (Flutter MSIX), per policies/windows-builds.kmd.
android active 2026-05-26 — Runner ci-runner-android (s.khost1.ci-runner-android) provisioned + registered with labels android:host, flutter-web:host.
web active always — Flutter Web or templ+HTMX builds; deployed via infra/net/jet.
tizenos experimental 2026-05 — TV target; React build path exists, no shipping wave yet.
webos experimental 2026-05 — TV target; same posture as tizenos.
browser active always — Extension/embed targets.
universal active always — Multi-target Dart/Go libraries.
chromium active 2026-05-30 — Extension engine for ChromeEdgeBrave (MV3). Per kruze-RFC-001; Chrome Web Store publisher account pending (accounts.md).
gecko active 2026-05-30 — Extension engine for Firefox (MV3). Per kruze-RFC-001; AMO publisher account pending (accounts.md).
safari inactive 2026-05-30 No macOS runner — Safari Web Extension requires safari-web-extension-converter + Xcode app-wrapper on a Mac (same gate as macos/ios). Per kruze-RFC-001. Code paths stay portable (WebExtension MV3); wrapper build gated until hardware lands.
macos inactive 2026-05-28 No macOS runner available. Apple toolchain (Xcode, codesign, notarytool) requires macOS hardware; no Mac is provisioned in the EVEO DC or on the laptop network. Acquisition pending owner decision (kruze#142 + future SDKKIT-macos tickets). Components may keep macos in koder.toml [app] platforms as a planned target. CI jobs MUST gate if: false. Code paths that touch macOS APIs (e.g. flutter_secure_storage Keychain backend in secure_key_store.dart) remain wired so the path is testable as soon as the hardware lands.
ios inactive 2026-05-28 Same as macos — Apple toolchain requires a Mac for flutter build ios, xcodebuild, codesign, and TestFlight uploads. Also requires Apple Developer Program enrollment (see meta/context/infrastructure/accounts.md). Same posture as macos. Components like dek, chat, pass keep ios in platforms as planned; CI jobs gated; code paths (Associated Domains, iOS-native download manager per kruze#148.2.2, etc.) stay in the tree.

How to flip a target from inactive to active

  1. The owner provisions the hardware/toolchain that resolves the gating condition.
  2. The runner is registered in the Flow admin/actions/runners registry

    (for macos / ios: a Mac with gitea-actions runner labeled macos-latest:host and an iOS Simulator or device farm).

  3. This row's Status flips to active; Since is set to the flip date;

    Gating condition is moved to a "Historical gates" note at the bottom of the file.

  4. Every CI workflow with if: false (or equivalent) for that target is

    reactivated in the same commit that flips the row. A grep for target-readiness.md across the monorepo surfaces the gated sites.

  5. Each component that listed the target as planned exercises its build

    in the next release wave; failures surface as net-new tickets.

How to mark a target as inactive (regression / hardware loss)

  1. Owner ratifies the regression (lost a runner, dropped a partnership, etc.).
  2. Flip Status here and document the gating condition.
  3. Add if: false to every workflow that targets the (now-inactive) target.
  4. Components keep the target in [app] platforms if it's still a planned

    future target; otherwise remove it.

  5. Open a ticket whose closure condition matches the gating condition so

    it's tracked instead of forgotten.

Cross-references

  • specs/variants/taxonomy.kmd §Target — canonical target enumeration
  • registries/koder-id-auth-coverage.md — per-component per-surface

    conformance grid (the surface definitions S2 mobile = Android + iOS and S3 desktop = Linux + macOS + Windows remain descriptive regardless of what ships; auth coverage for inactive targets is naturally N/A until flip)

  • meta/context/infrastructure/servers.md — runner inventory
  • meta/context/infrastructure/accounts.md — Apple Developer Program (when applicable)