https://www.gokure.dev/launcher/dev/concepts/index.htmlThe launcher design, the OAM data model, and the key design decisions behind kurel packages.Hugoen-ushttps://www.gokure.dev/launcher/dev/concepts/design/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://www.gokure.dev/launcher/dev/concepts/design/index.htmlLauncher — Design Document Date: 2026-04-19 | Updated: 2026-05-15 | Status: Phase 0 design complete Version Date Summary 1.3 2026-05-15 Replace patch-centric §4 with OAM-native pipeline; add OAM model, Policy interface, launcher layout, and what-launcher-does-not-do sections; update roadmap 1.2 2026-05-14 Record all Phase 0 decisions; add §9 decisions table; update roadmap; trim open questions 1.1 2026-05-14 Update GVK, roadmap, and open questions for second design iteration 1.0 2026-04-19 Initial draft 1. Vision Launcher is an OAM-inspired package manager for Kubernetes — a semantically richer alternative to Helm.https://www.gokure.dev/launcher/dev/concepts/oam-gvk/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://www.gokure.dev/launcher/dev/concepts/oam-gvk/index.htmlDesign: API Group and Document Ownership Status: Final | Prerequisite for: design-cluster-profile.md, design-kurel-package.md, options-policy-interface.md Version Date Summary 1.0 2026-05-14 Initial — records GVK decision, rationale, strictness rule, OAM reuse Design Statement Launcher defines its own native application model under launcher.gokure.dev/v1alpha1. The model is inspired by OAM concepts — applications, components, traits, and capability-driven rendering — but launcher does not claim native API compatibility with core.oam.dev/v1beta1. Standard OAM import/export compatibility may be supported later through a translation layer.https://www.gokure.dev/launcher/dev/concepts/oam-package/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://www.gokure.dev/launcher/dev/concepts/oam-package/index.htmlDesign: Kurel Package Spec Status: Final | Issue: #36 Version Date Summary 1.1 2026-05-14 Complete §6 (parameter syntax — Option A); fix GVK references; remove backup from Phase 1 trait table; fix §5 diagram label 1.0 2026-04-19 Initial draft — parameter syntax section omitted pending decision 1. Purpose A kurel package is a distributable, reusable OAM application pattern. It bundles:https://www.gokure.dev/launcher/dev/concepts/oam-cluster-profile/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://www.gokure.dev/launcher/dev/concepts/oam-cluster-profile/index.htmlDesign: Platform Profile — ClusterProfile Status: Final | Issue: #37 Version Date Summary 1.1 2026-05-14 Remove parameters field; update GVK to launcher.gokure.dev/v1alpha1; add strictness rule; add migration guide 1.0 2026-04-19 Initial draft 1. Purpose A ClusterProfile tells the launcher runtime how the platform implements each trait. It is an environment-level document, written once per cluster by the platform operator and shared across all applications deployed to that cluster.https://www.gokure.dev/launcher/dev/concepts/oam-param-syntax/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://www.gokure.dev/launcher/dev/concepts/oam-param-syntax/index.htmlDesign: Parameter Syntax for Kurel Packages Status: Final — Option A selected | Issue #36 Version Date Summary 1.1 2026-05-14 Record decision (Option A); remove Option B; add resolver behaviour section; correct env list claim 1.0 2026-04-19 Initial draft — compared Option A (placeholders) and Option B (overlay) Decision: Application values are expressed as ${var} placeholders in app.yaml, with a typed parameter schema declared in kurel.yaml. Reason: launcher is a package manager; an explicit, machine-readable package API (schema, required fields, types, --set support) is more important than app.yaml being valid at rest.https://www.gokure.dev/launcher/dev/concepts/oam-capability-schema/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://www.gokure.dev/launcher/dev/concepts/oam-capability-schema/index.htmlDesign: Capability Rendering Schema Status: Final | Issue: #60 Version Date Summary 1.0 2026-05-16 Initial — records built-in struct pattern and custom CapabilityDefinition plan 1. Scope This document answers two questions deferred from design-cluster-profile.md §2: Built-in handlers — where does the schema of accepted rendering keys live, and how is it validated? Custom capabilities — how does a downstream consumer declare the rendering schema for a non-built-in handler? Out of scope here:https://www.gokure.dev/launcher/dev/concepts/oam-policy-interface/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://www.gokure.dev/launcher/dev/concepts/oam-policy-interface/index.htmlDesign: Policy Interface Status: Final — Option A selected | Issue #38 Version Date Summary 1.1 2026-05-14 Record decision (Option A); add framing section; rename options A/B; remove Option B 1.0 2026-04-19 Initial draft — compared typed accessor (Option A) and opaque marker (Option B) Decision: oam.Policy is a typed accessor interface with 18 methods. Reason: compile-time verification, no type assertions in handler code, and explicit NoopPolicy behaviour (no limits, no defaults, security-sensitive bools default-deny) are more important than the flexibility of a marker interface for future policy types.https://www.gokure.dev/launcher/dev/concepts/oam-package-composition/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://www.gokure.dev/launcher/dev/concepts/oam-package-composition/index.htmlDesign: Package Composition — Optional Sections, Multi-Instance, Split Files Status: Final — deferred to Phase 2 (issue #39) | Issue #36 Version Date Summary 1.1 2026-05-14 Record decision (Phase 2 deferral); remove mechanism sections; keep background and open questions for #39 1.0 2026-05-14 Initial draft — compared kurel.yaml optional list (Option A) and inline include-if annotation (Option B) Decision: No optional sections, multi-instance, or split-file support in Phase 1. Package authors publish always-on packages. Users who need deployment variants instantiate separate packages. Composition mechanism is designed in Phase 2 (issue #39).