RFC: Verified Extension Ecosystem (VEE) — lean kernel, external modules, CI-verified catalog #468

lkmavi · 2026-08-17T12:06:24Z

lkmavi
Aug 17, 2026
Collaborator

Status: open for feedback — ecosystem architecture (not ui-repo-only)
Scope: GoGPU org · kernel gogpu/ui · catalog gogpu/widgets · optional uicore / uiplugin
Labels: architecture, extensibility, supply-chain, module design
Related: gogpu/ui#65 (widget collection), prior threads on third-party extensibility / custom widgets / UI RFC
Builds on: ADR-034 (Painter/behavior), ADR-036 (extensibility), SceneCache (gogpu/ui#210), ADR-057 (Widget Authoring SDK, proposed)
Moved from: gogpu/ui#229 (body + catalog clarification merged here)

TL;DR

We agree with the Widget Ecosystem RFC direction: SDK, Tier-2 golden path, ThemeBundle, and a catalog are the right pre-v1.0 bets.

We propose a sharper distribution model:

gogpu/ui = lean kernel + contracts.
Community widgets = separate Go modules (go get).
gogpu/widgets = curated index + CI gates — not a source warehouse.

Goal: extensibility without core bloat, predictable binary size, and enterprise-grade trust for third-party packages.

Context (what the RFC already got right)

Extension mechanisms in gogpu/ui already work: widget, registry, theme, layout, plugin, cdk, painters / LayoutMetrics. SceneCache cut the widget/ compile surface (124 → 70 packages).

What’s missing is not API surface — it’s the product around the API:

Tier-2 DX — themeable + signals + a11y + Painter without hand-assembling 7+ packages.
Discoverability — a place to find vetted community widgets (feat: implement W3C Pointer Events for all platforms (EVENT-005) #65).
Kernel boundaries — risk that a “convenient” catalog becomes a monorepo and inflates ui / final binaries / download surface forever.

go get github.com/gogpu/ui still downloads the entire module. Community code inside ui grows download size, review surface, and permanent core maintenance pressure.

Principles

Lean kernel — only what most apps need and the org will support indefinitely.
Opt-in dependencies — third-party widgets enter an app only via explicit require / import.
Catalog ≠ codebase — the index points at modules; it does not vendor their sources.
CI as a trust product — “verified” means a compatibility matrix passed, not “someone starred it.”
Contracts before runtimes — WASM/RPC interfaces may freeze before 1.0; runtimes must not block SDK + catalog.
One Widget — sdk/ never introduces a second widget API; façade only over existing packages.

Architecture: three layers

┌──────────────────────────────────────────────────────────────┐
│ L0  KERNEL — github.com/gogpu/ui                             │
│     primitives + stable core widgets                         │
│     layout / theme / registry / plugin / cdk / uitest / a11y │
│     sdk/ (façade)                                            │
│     Rule: community widgets are NOT accepted here            │
└──────────────────────────────▲───────────────────────────────┘
                               │ go.mod require (semver / compat)
┌──────────────────────────────┴───────────────────────────────┐
│ L1  EXTENSION MODULES — independent Go modules               │
│     github.com/alice/ui-rating                               │
│     github.com/acme/gogpu-datagrid                           │
│     (optional) github.com/gogpu/ext-*                        │
│     Install: go get + import / blank import                  │
└──────────────────────────────▲───────────────────────────────┘
                               │ PR to index + CI attestation
┌──────────────────────────────┴───────────────────────────────┐
│ L2  CATALOG — github.com/gogpu/widgets                       │
│     index.yaml / entries/*.yaml + docs                       │
│     No widget sources (docs/schemas only)                    │
│     CI: compat × ui versions × platforms                     │
│     Badge: verified @ module@version vs ui@…                 │
└──────────────────────────────────────────────────────────────┘

Layer	Owner	Ships	Does not
L0 Kernel	gogpu org	APIs, contracts, reference themes, TestKit	Accumulate domain/community widgets
L1 Module	author / company	widget, theme, layout, plugin bundle	Require a merge into `ui`
L2 Catalog	gogpu org	index, CI gate, badges, submit docs	Host binaries; proxy.golang.org is the artifact store

Core inclusion criterion

A widget/package lands in ui only if:

roughly ≥ 70% of apps need it, and
the org will support it forever, and
it is design-system basics, not domain-specific.

In core	Outside core (L1)
Button, TextField, Checkbox, Radio, Slider, List, Dialog, Menu, Tabs, …	Charts, Markdown, CodeEditor, Calendar, Maps, RichText, CRM/domain
`widget`, `registry`, `theme`, `layout`, `plugin`, `cdk`, `uitest`, `a11y`	Community painters / corporate ThemeBundles
M3 / Fluent / Cupertino as reference ThemeBundles	Nordic and other community design systems
`sdk/` façade	WASM runtime, editor RPC hosts

Any “please merge X into core” request goes through an RFC + the criterion above.

Stock widgets are optional — bring-your-own kit

The desire to “skip the stock UI and ship my own kit for binary size” is valid. A “turn off the original UI” switch (build tags / runtime flag) is not.

Stock widgets already live in separate packages (core/button, core/textfield, …). The app / desktop runtime path depends on widget (contracts), not on the whole core/* tree. In Go, unimported packages stay out of the binary — savings come from not importing, not from a kill switch.

Supported composition path (document in the SDK):

Scenario	What to do
Full custom kit	`app` + `widget` + layout/theme contracts + your L1 modules; no `core/*`, no reference ThemeBundle
Custom look, stock behavior	ThemeBundle / painters over stock widgets
Custom look + behavior	your widgets on `widget.Widget`; publish as a normal L1 module
Thinner download/review surface	later, on measurable pain — extract `uicore` (types without the stock kit)

import (
    "github.com/gogpu/ui/app"
    "github.com/gogpu/ui/desktop"
    "github.com/gogpu/ui/widget"
    // no github.com/gogpu/ui/core/...
    // no github.com/gogpu/ui/theme/material3
    my "github.com/acme/mykit"
)

Analogy: Angular CDK without Material — not “Material with an off toggle.”

Honest binary-budget note: GPU stack weight (gg / wgpu / fonts) often dominates a single Button. Skipping stock widgets is a useful opt-in, not a silver bullet. Catalog CI binary budgets catch extension Δ size surprises; they do not invent a magical disable.

Explicitly out of scope for A–C: build tags on the stock kit, a runtime “disable default UI” flag, or a single “all widgets” package with opt-out (that would fight dead-code elimination).

Extension contracts (lock before v1.0)

1. SDK (`sdk/`)

Thin surface: re-export stable types, registration helpers, testing helpers.
Success metric: empty module → themeable + tested + registered widget in < 1 hour (Tier 2).

Accompanied by examples/custom_widget/ and docs/sdk/ (including publishing).

2. Registry metadata (backward compatible)

Optional fields on registry.WidgetInfo: Author, Module, License, Tags, Homepage, Themes.

3. `widget.yaml` (out-of-band)

For catalog tooling and CI — not part of the Go runtime. Describes module, ui_compat, entrypoints, tests, tags.

4. ThemeBundle

One call: app.New(app.WithThemeBundle(nordicui.NewTheme())). Community themes live in L1.

5. Consumer UX

import (
    // Catalog entry — verified against ui@v0.4.2
    _ "github.com/alice/ui-rating"

    "github.com/gogpu/ui/app"
)

Recommendation: prefer an explicit API over blank import (auditability, fewer surprises). Blank import remains an opt-in for discovery/registry.

Catalog `gogpu/widgets` (L2)

At launch: no ratings, reviews, or payments. Selection = quality + CI. Artifacts = Go module proxy.

Mental model: Obsidian-style catalog (index only)

A useful mental model for L2 (gogpu/widgets) is Obsidian community plugins:

Obsidian	GoGPU VEE
Author keeps the plugin in their own GitHub repo	L1: independent Go module (`github.com/alice/ui-rating`)
Release / tag	Semver tag (`v0.3.1`)
PR into the community index (`obsidian-releases`)	PR into `gogpu/widgets` (`entries/*.yaml`)
Review + quality gate	Submit-gate CI (+ optional human review)
Catalog points at the author — does not vendor sources	Index-only: no widget sources in our repo
User installs from the catalog	`go get module@version` + import

What we do: discoverability, review, CI attestation, catalog links.
What we do not do: host widget source/binaries. Artifacts come from the author’s module via proxy.golang.org; integrity from sum.golang.org.

Where Go is stronger than a typical plugin zip store:

Checksums by default — sumdb pins module@version; retagged history does not silently win.
Compile-time install — predictable binary, SBOM (go list -m all), reproducible builds (vs downloading plugins at runtime).
Semver + MVS — ui_compat + CI matrix, not “latest zip from GitHub”.

So the org is a curated index + trust gate, not a code warehouse — same spirit as Obsidian’s registry, with Go’s module proxy as the artifact store. A future catalog website can sit on the same index.yaml without changing this model.

Tier	Meaning	How earned
`community`	In the index; CI green on submit	PR + submit gate
`verified`	Periodic re-check against current `ui`	nightly/weekly bot
`org`	Under `gogpu/*` or signed MoU	org maintainers

Honest docs wording:

Verified ≠ security audit.
CI guarantees build, tests, and API compatibility with listed ui versions. Full author-code security review remains the consumer’s / their SDLC’s responsibility.

CI as the trust product

Submit gate: resolve → static checks (go vet / staticcheck, no CGO, OSI-compatible license) → compat matrix (recent ui minors + tip) → platform smoke → (recommended) binary budget → attestation written into the entry.

Nightly re-verify: failure → status: broken + author notification. Green badge only while the suite stays green.

Example attestation fields:

attestation:
  verified_at: 2026-08-08T12:00:00Z
  ui_versions: [v0.4.1, v0.4.2]
  commit: abcdef0123456789
  workflow_run_id: "123456789"
  binary_delta_bytes: 184320

Answers to the RFC open questions

#	Question	Proposal
Q1	Extract a foundation module?	Not required now. First: lean-kernel policy + index-only catalog + `sdk/`. Extract `github.com/gogpu/uicore` only if measurable download/CI pain remains.
Q2	Naming (if extract)	`uicore` for minimal types; `sdk/` stays a package inside the kernel; `widgets` = catalog only; `uiplugin` for WASM/RPC later. Avoid `uisdk` as a module name (collides with package `sdk/`).
Q3	Would you use WASM runtime plugins?	Yes for IDE/editor/hot-plugins. No as the primary enterprise path for app widgets. Primary path: compile-time `go get` → predictable binary, SBOM, audit, reproducible builds.
Q4	Where should WASM/RPC interfaces live?	Separate module `gogpu/uiplugin`. Do not pull wazero / RPC hosts into every app that draws a Button.
Q5	Priority	P0: `sdk/` + Tier-2 example + docs. P0/P1: index-only `widgets` + submit CI. P1: ThemeBundle + registry metadata. P2: nightly re-verify + binary budget. P3: optional `uicore`; WASM/RPC runtime (contracts earlier if cheap).

Explicitly out of scope for phases A–C

ui/contrib as a community widget dump
a widgets monorepo with dozens of Go packages (bloat under another name)
a ratings marketplace
binary hosting instead of the Go proxy
a stock-UI “kill switch” (build tags / runtime flag) — use BYO-kit via not importing core/* instead

Phased plan (refinement of the RFC timeline)

Phase	Scope	Outcome
A	`sdk/` + `examples/custom_widget/` + `docs/sdk/`	Tier 2 < 1h
B	`gogpu/widgets` (index-only) + `widget.yaml` + submit-gate CI	pluggable + verified links
C	ThemeBundle + extended `WidgetInfo` + compat badges	enterprise DX
D	Nightly re-verify + binary budget + community process	trust at scale
E	WASM/RPC contracts → later runtime (`uiplugin`)	editor/IDE path

Delta vs the original RFC phasing: pull the catalog earlier (alongside SDK); push WASM runtime lower (contracts can still land early if cheap).

Governance (short)

Core freeze — new core widget only via RFC + ≥70% / perpetual-support criterion.
Catalog contribution — DCO/CLA on the entry; sources stay with the module author.
Security posture — vuln in a verified entry → demote + advisory; org guarantees the suite, not “we vouch for all author code.”
Deprecation — status: broken on failed nightly; README/badge reflect reality.
SBOM — consumers use go list -m all; the catalog helps pin known-good versions.

Why this is enterprise-grade

Pattern	Our analogue
`database/sql` driver model	contracts in kernel, implementations outside
Angular CDK	stable primitives/contracts; UI kit separate as needed
VS Code extension marketplace (without store UI)	index + verification, no mandatory binary host
Go module proxy	sole artifact store
Flutter package `sdk` constraints	`ui_compat` in `widget.yaml` + CI matrix
SLSA-inspired attestations	`workflow_run_id` / commit / `verified_at` in entries

Consumer outcome:

go get github.com/alice/ui-rating@v0.3.1
# catalog link + badge: verified against gogpu/ui@v0.4.2

Kernel outcome: ui size and surface grow only from org decisions — not from community activity.

Proposed decision

Accept the RFC direction on SDK / ThemeBundle / catalog / pre-1.0 contracts.
Adopt VEE: lean kernel + external modules + CI-verified catalog.
Prioritize Phase A+B before 1.0.
WASM/RPC — contracts optional early; runtime later in uiplugin.
Extract uicore — non-blocking; only on measurable need.

How to participate

We need feedback on:

Kernel boundary — agree with ≥70% / no community code in ui?
Trust tiers — are community / verified / org enough?
Binary budget in CI — hard-fail on Δ size from day one, or report-only first?
Blank vs explicit import — what should docs recommend as the default?
First reference extensions — which 2–3 modules should run the pipeline first (catalog smoke)?
BYO-kit — do we need a first-class docs/example for “app + widget only, zero core/*”, or is an SDK mention enough?

Comment below. Every perspective helps us lock the right extensibility story before v1.0.

GoGPU ecosystem — Pure Go, zero CGO. Extensions opt in explicitly; kernels stay lean. This is an org-level architecture discussion.

kolkov · 2026-08-17T12:19:47Z

kolkov
Aug 17, 2026
Maintainer

Thank you for the thorough proposal. VEE brings structure to a set of questions we've been working through in ADR-034, ADR-036, and the extensibility research. This response is our analysis and open questions — not final decisions. We want the community to weigh in before anything is locked.

This is an ecosystem-level discussion, now alongside the naming RFC (#377) and Neon RFC (#328). Contributors across all repos are welcome.

What we've studied

We've accumulated significant research on extensibility: ADR-034 (Painter/behavior separation, partially implemented), ADR-036 (SceneCache — done, module extraction and plugin interfaces — open), three dedicated research reports (15 frameworks analyzed, 4 WASM runtimes evaluated), and now VEE. The consolidation report identified where proposals agree, where they conflict, and what gaps remain.

The core extensibility mechanisms (Painter pattern, LayoutMetrics, ThemeBundle interface, registry, plugin manager, CDK) are implemented and shipping. What's missing is the product around these mechanisms: documentation, examples, ThemeBundle implementations, and a clear path for community widget authors.

Topics that need discussion

1. Single module vs extraction — conflicting evidence, open question

Our own documents disagree on this:

ADR-036 recommends foundation extraction before v1.0: "Go has NO tree shaking. If you import a package, you compile everything it imports. This makes foundation extraction more important in Go than in Dart/TypeScript."
GO-MODULE-EXTENSIBILITY-ARCHITECTURE research report recommends single module with trigger conditions for revisiting.
VEE says "not required now."

SceneCache reduced widget/ compile surface from 124 to 70 packages, which resolved the immediate pain. But the deeper question — whether third-party widget authors should depend on the full gogpu/ui module or a lighter contracts module (similar to gpucontext for the GPU stack) — remains open.

What we need to figure out:

What's the actual cost of depending on gogpu/ui for a third-party widget module? (download size, compile time, transitive deps)
Would a gogpu/uicore or similar contracts module (like gpucontext) give third-party authors a significantly lighter dependency?
At what scale does this matter?

This is one of the most consequential pre-v1.0 decisions. Community input is valuable here.

2. Where does the "kernel" live and what exactly is it?

VEE proposes L0 (kernel) = gogpu/ui. This needs deeper justification:

Is gogpu/ui the right home for the kernel, or should contracts live in a separate lightweight module (like gpucontext for the GPU stack)?
What exactly constitutes the kernel? widget/ + event/ + geometry/? Or also registry/ + theme/ + layout/?
The ≥70% criterion for core inclusion is a useful heuristic, but the specific threshold and the "perpetual support" commitment need careful thought

These are architectural questions that benefit from community input before we commit.

3. sdk/ — what, where, and how

All proposals agree an authoring experience improvement is needed. The questions:

What goes in it?

Registration helpers? Testing helpers? Documentation entry point?
VEE says thin facade + helpers. Our analysis suggests the real gap is documentation and examples, not necessarily a Go package.

Where does it live?

Package inside gogpu/ui (e.g., sdk/)?
Separate repository (like gpucontext or gputypes)?
If separate — what's the module path? gogpu/uisdk? gogpu/ui-sdk?

How do we validate the design?

We propose building examples/custom_widget/ FIRST — a Tier 2 widget with Painter, LayoutMetrics, signals, a11y. This reveals whether sdk/ helpers are genuinely needed or if good documentation suffices.
Same approach we used with compose: start with working code, extract patterns into a library.

4. ThemeBundle — interface exists, implementations needed

theme.Bundle interface is defined and the design looks correct. Four built-in implementations (M3, DevTools, Fluent, Cupertino) and app.WithThemeBundle() wiring are needed before community theme authors can use this path. This is ADR-034 Phase 3, partially tracked.

The wiring question is non-trivial: how does WithThemeBundle() set painters on widgets? Walk the tree at construction? Use the registry? Lazy resolution during Draw? This needs design work.

5. Catalog — interesting model, needs validation

The L2 index-only catalog (Obsidian parallel) is an interesting model. CI attestation with trust tiers is well-thought-out.

The catalog infrastructure, trust tiers, and CI attestation should all be in place before v1.0 — so the ecosystem launches with a complete contribution path, not a "coming soon" placeholder.

Open questions on design:

widget.yaml schema — what fields, what validation rules?
CI attestation — what exactly does the submit gate check?
Reference extensions — which 2-3 modules validate the pipeline end-to-end?

6. WASM/RPC — analysis shows existing interfaces are sufficient

We analyzed whether existing interfaces need modification to support WASM/RPC plugins:

A host-side proxy widget implements widget.Widget and translates Layout/Draw/Event to RPC calls
Canvas methods serve as the draw command vocabulary — no changes needed
gesture.GestureAware — proxy implements it if the plugin declares gestures
All painter interfaces — same proxy pattern

Finding: all plugin-specific types are purely additive — new types in a new module (gogpu/uiplugin). Zero modifications to existing gogpu/ui interfaces required. This means plugin support can ship at any version without breaking changes.

VEE's position ("contracts earlier if cheap; runtime later") aligns with this analysis. Plugin type vocabulary (DrawCommand, PluginSession, etc.) should be defined before v1.0 as part of the stable contract surface. The WASM/RPC runtime implementation (gogpu/uiplugin) ships when editor/IDE requirements are concrete — but the contracts are locked early.

7. Extended registry metadata

Additional fields on WidgetInfo (Author, Module, License, Tags, Homepage, Themes) are straightforward — additive fields with zero-value defaults, no breaking changes. These should be part of the pre-v1.0 work alongside the catalog schema.

What's clear vs what's open

Clear (consensus across all proposals):

Painter pattern is the core extensibility mechanism ✅
Compile-time Go packages are the primary extension model ✅
ThemeBundle interface design is correct (needs implementations) ✅
SceneCache solved the compile surface problem ✅
go plugin package is ruled out ✅
WASM/RPC runtime in separate module ✅
No community code in core ✅

Open (needs discussion and/or validation):

Single module vs extraction — conflicting evidence, untested at scale
Kernel boundaries and location — needs justification
sdk/ scope, naming, and repository — needs golden-path example first
Catalog infrastructure and governance — schema, CI gate, trust tier design
≥70% inclusion criterion — useful heuristic, threshold needs thought
Plugin contract vocabulary — depends on editor/IDE requirements
ThemeBundle wiring mechanism — needs design

Next steps we're considering

Build examples/custom_widget/ to validate the extension authoring experience
Complete ThemeBundle implementations (ADR-034 Phase 3)
Update docs/EXTENSIONS.md (currently at v0.4.x, March 2026 — outdated)
Use concrete experience from steps 1-3 to make informed decisions on the open questions above

We'd value community input on

Kernel boundaries — what should be in the kernel and why? Is gogpu/ui the right home, or do contracts belong in a separate lightweight module?
sdk/ location — package in gogpu/ui, separate module, or just documentation?
Catalog design — what should the submit gate CI check? What fields in widget.yaml?
First reference extensions — which 2-3 modules should validate the pipeline end-to-end?
BYO-kit — how important is "app + widget only, zero core/*" as a documented path?
Blank vs explicit import — what should docs recommend for widget registration?

@lkmavi your Obsidian parallel is a strong mental model — the "curated index + trust gate, not a code warehouse" framing clarifies L2 well. The Go module proxy as artifact store (with sumdb integrity) is strictly better than zip-based plugin stores.

We'd like to hear from community members who've built on or evaluated gogpu/ui:

@besmpl — as the top external contributor (20+ PRs, Android arm64), how would the extension model affect your workflow? Would you publish widgets as L1 modules?
@samyfodil — you've contributed cross-repo (wgpu, gg, gogpu). Does the L0/L1 boundary make sense from a multi-repo contributor perspective?
@AgentNemo00 — you originally requested a widget collection (feat: implement W3C Pointer Events for all platforms (EVENT-005) #65). Does the VEE catalog model (index + CI verification) address your need?
@kivutar — you're building Goro (Ragnarok Online client) on gogpu/gg. Would you use the extension ecosystem for game UI widgets? Does the BYO-kit path (app + widget, no stock core/*) match your use case?
@porjo — you've contributed to g3d and validated damage rect behavior on Wayland/Asahi. Does the L0/L1 split make sense for 3D-integrated widgets?
@jdbann — you contributed Metal PRs to wgpu. Would a theme/painter extension model work for platform-specific rendering paths?
@darkliquid — you built ironwail-go (Quake) on gogpu. Does the BYO-kit path (custom rendering, no stock widgets) match game engine UI needs?
@unxed — you participated in the Neon RFC (RFC: Pure Go GPU Driver (neon) — Direct Hardware Access #328). How does the extensibility model interact with low-level GPU access?
@jbunds — you raised macOS integration questions. Platform-specific extension patterns are relevant here.
@TimLai666, @omer316, @OkieGo — you participated in the naming RFC (RFC: Library Names for the GoGPU Ecosystem #377). The sdk/ and catalog naming questions could use your input.
@crystalthoughts, @tmssngr, @bidzhao, @wyaode — you've been active in ui discussions. We'd value your perspective on the extension authoring experience.

If you know anyone building on gogpu or evaluating Go GUI frameworks — please share this discussion. The more perspectives we get before v1.0, the better the architecture.

We'd also appreciate if community members could bring this topic to broader Go forums — Reddit (r/golang), Hacker News, Go Discord, or any other channels where Go developers discuss GUI frameworks. The extensibility architecture affects everyone who will build on gogpu, and we want input from beyond our immediate community. If you have access and think this is worth discussing — please post and link back here.

gogpu/ui — enterprise GUI toolkit for Pure Go. We're laying the extensibility architecture before v1.0 — all of it. Every perspective helps us get it right.

7 replies

kolkov Aug 17, 2026
Maintainer

Pinging game developers in the community — this thread is directly relevant to game UI architecture:

@kivutar — you're building Goro (Ragnarok Online client) on gogpu/gg. The Canvas gap analysis above (gradients, sprite atlas, paths) and the Painter-based theming model are exactly what game UIs need. Would the ImageRegionDrawer interface (sprite sheet / texture atlas support) be useful for Goro's inventory/UI rendering?

@besmpl — Hearth game engine on gogpu. How does the BYO-kit path (app + widget, no stock core/*) fit your engine's UI needs? And with Android arm64 support landing — does the extensibility model work for mobile game UI?

@BrentFarris — you expressed interest in gogpu integration for KaijuEngine. The GPUView widget (offscreen GPU texture composited in the Layer Tree) is designed for exactly this — 3D game viewport with UI overlay. Would the Painter + LayoutMetrics model work for KaijuEngine's UI layer?

AgentNemo00 Aug 17, 2026

Yes, a widget collection would be optimal. I need something which is verified and works even after it may be abandoned.
How would you handle the usecase of the an abandoned repo/widget which depends on an older kernel version.

Is the kernel always compatible with older versions ? Since v1.0 ?
Would a new version trigger a new verification of each widget in the collection ?
What happens if the widget is not compatible anymore ? Keep it in the catalog as long as the major version is compatible ?

kolkov Aug 17, 2026
Maintainer

These are exactly the right questions — widget lifecycle is where catalog design gets real.

Abandoned widget + old kernel version

Go's module proxy (proxy.golang.org) caches every published version permanently. An abandoned widget at v0.3.1 that worked with ui@v0.4.2 will always be installable at that exact combination:

go get github.com/alice/ui-rating@v0.3.1
# works forever — proxy has it cached, sumdb has the checksum

The widget doesn't disappear when the author stops maintaining it. It just stops getting updates.

Kernel backward compatibility

Go semantic versioning guarantees:

v1.x → v1.y — backward compatible. A widget built for ui@v1.0.0 works with ui@v1.5.0. No import path changes.
v2.0 — would be a new import path (gogpu/ui/v2). We plan to avoid v2.0 entirely — that's why we're doing the architecture work now, before v1.0.

So yes, within v1.x, the kernel is always compatible with widgets built for older v1.x versions. That's Go's compatibility promise.

New version triggers re-verification

The VEE proposal includes nightly/weekly CI re-verification. When a new ui version is released:

CI runs each cataloged widget's tests against the new version
If tests pass → badge stays green, verified_at timestamp updated
If tests fail → status changes to broken, author notified
The catalog entry stays — it just shows the last-known-good version

This is automated — no manual review needed for re-verification.

What happens with incompatible widgets

A widget that breaks on a new kernel version:

Scenario	What the catalog shows
Widget works with ui@v1.2 but not v1.3	`verified: ui@v1.2` (green) + `broken: ui@v1.3` (red)
Author fixes it	Re-submit → CI re-verifies → back to green
Author never fixes it	Entry stays with last-known-good version. Users can still `go get widget@v0.3.1` and pin `ui@v1.2` in their go.mod
Major version break (ui v2.0, if ever)	Separate catalog section. v1 widgets stay in v1 catalog

The key principle: the catalog never removes entries. It shows reality — green means verified now, red means broken now, and the version history tells users exactly which combinations work.

What makes this different from npm/crates.io

Go's module system has two properties that make abandoned packages less dangerous than in npm:

sumdb — checksums prevent silent modification of published versions. Even if the author's repo is compromised, go mod verify catches it.
MVS (Minimum Version Selection) — Go selects the oldest compatible version, not the newest. An abandoned dependency doesn't silently upgrade to a broken version.

So "verified and works even after abandonment" is actually Go's strength — the proxy + sumdb + MVS combination provides exactly this guarantee at the language level. The catalog adds CI attestation on top.

Does this address your concern? Any specific edge cases you're thinking about?

AgentNemo00 Aug 17, 2026

Thank you, that fully answers my questions.

To add my opinion to the board:

Kernel boundary — agree with ≥70% / no community code in ui?
I would add it whenever community widgets depend on it. i.e. a good collection of ui elements is being used in a couple of community widgets like a new theme.
Trust tiers — are community / verified / org enough?
yes, thanks to @kolkov explanation
Blank vs explicit import — what should docs recommend as the default?
Up to the widget author. I can not think about a usecase in which a ui element would need to only do discovery/registry.
First reference extensions — which 2–3 modules should run the pipeline first (catalog smoke)?
Take something from m3

kolkov Aug 17, 2026
Maintainer

Thank you for the concrete feedback on all four questions.

On the kernel boundary — "add it whenever community widgets depend on it" is a practical evolution of the ≥70% criterion. Instead of guessing upfront what belongs in core, let real usage drive it. If multiple L1 widgets converge on the same utility (e.g., a date formatting helper), that's the signal to promote it to L0.

The DatePicker suggestion from M3 is an excellent candidate for a reference L1 extension. We'd pair it with a ColorPicker — together they cover two distinct extension patterns:

Widget	Exercises	M3 Spec
DatePicker	Overlay (calendar popup), gesture (swipe months, tap dates), signals (selected date), a11y (ARIA grid), LayoutMetrics (cell sizes), i18n (locale-aware formatting)	M3 Date Pickers
ColorPicker	Custom Canvas drawing (gradient hue wheel, saturation/brightness plane), drag gesture (color selection), real-time preview, hex/RGB input via TextField	Common in design tools, image editors, theme builders

Both are clearly domain-specific (not every app needs them), complex enough to stress-test the full extension surface, and useful enough that real projects would adopt them. DatePicker validates the standard widget path (layout, overlay, a11y). ColorPicker validates the custom rendering path (Canvas gradients, advanced drawing, gesture drag on custom visuals) — exactly the game UI pattern @darkliquid raised.

We'll track both as candidates for Phase B catalog validation. If you'd be interested in testing either as an early adopter — that would be valuable real-world feedback.

darkliquid · 2026-08-21T19:11:07Z

darkliquid
Aug 21, 2026

@kolkov I set an agent attempting to port the quake UI as I currently have it implemented to use gogpu/ui. I've posted what it found here: darkliquid/ironwail-go#17 if you are interested in taking a look.

0 replies

zloymelnik · 2026-08-24T05:17:53Z

zloymelnik
Aug 24, 2026

Thank you for compiling this into a clear RFC — I strongly support the lean kernel + Obsidian-style catalog direction. In my view, this is not just a convenient distribution scheme, but a solid architectural plan for how the Pure Go GUI ecosystem should grow post-v1.0.

Why the Obsidian model fits GoGPU so well

Obsidian's community plugins have demonstrated a sound product principle: the platform owns the contracts and trust, authors own source code and release cycles, and the catalog is an index with gates, not a monorepo that sucks in every popular extension.

Mapping to VEE:

This separation directly addresses the risks outlined in the RFC:

The kernel does not become a warehouse. Charts, Markdown, CodeEditor, calendars, domain-specific kits, enterprise ThemeBundles stay outside ui. The kernel remains maintainable "forever."
Applications stay opt-in. The consumer pays only for what they explicitly require / import. Dead-code elimination stays honest — no fake "disable stock UI" toggle.
Maintenance scales. The organization reviews index entries and CI attestations, not every line of every community widget.
Authors move at their own pace. Semver tags, breaking changes, and experimental APIs live in L1 and do not block kernel releases.

This is exactly the model I had in mind when comparing to Obsidian: curated discoverability without the pressure of "everything in one tree" and without an untrusted zip-store.

Distribution via Go proxy — a key enhancement to the scheme

What makes this stronger than a typical plugin marketplace is that installation and integrity are already solved by Go's module system:

The catalog entry points to a module@version (the author's module).
The consumer installs with the standard toolchain: go get github.com/alice/ui-rating@v0.3.1.
Bytes come from proxy.golang.org (or from a private proxy in enterprise).
Integrity is pinned by sum.golang.org — retags / rewritten history do not pass silently.
The dependency graph is auditable: go list -m all, SBOM, reproducible builds.

Therefore, L2 should remain index-only: YAML entries, docs, schemas, badges, CI matrix. No vendoring of widget sources into gogpu/widgets. The catalog stays small and reviewable, and "verified" means attestation of compatibility with specific ui versions and platforms, not popularity.

The compile-time model is also better than runtime plugin downloading as the default for desktop GUI:

predictable binary contents;
no unexpected network fetches on startup;
clear license / supply-chain surface at build time;
WASM/RPC can be added later as a separate path (uiplugin), without breaking the main L1 scenario.

Why this is a good architectural plan (not just packaging)

The three layers correctly define boundaries of dependencies and trust:

L0 Kernel — primitives, stable contracts (widget, layout, theme, registry, plugin/cdk), reference ThemeBundle, TestKit/SDK facade. The inclusion criterion (≥70% of apps + perpetual support + not domain-specific) is a good heuristic, even if the threshold is refined later.
L1 Modules — the real extension surface. Same Widget type, no second API. ThemeBundles / painters / custom kits are published as ordinary modules.
L2 Catalog — the product-level wrapper for trust and discoverability without owning the code.

This aligns well with GoGPU's existing ecosystem pattern (gpucontext / gputypes as contracts, implementations separate): contracts and lean core first, then optional modules, then a curated index.

I also agree with the order of work in the RFC:

Lock down contracts / SDK golden path before v1.0
Polish ThemeBundle wiring so community themes become real
Stand up catalog CI and 2–3 reference L1 modules end-to-end
Keep WASM/RPC vocabulary additive; runtime — when concrete editor/IDE requirements emerge
Postpone extracting uicore until there is measurable pain — SceneCache has already reduced compile surface; don't over-split prematurely

On the open questions, my lean:

Where the kernel lives: start with gogpu/ui as L0; extract uicore only if download/compile cost for third-party authors genuinely hurts.
sdk/: a thin facade inside ui is fine if examples/custom_widget/ shows helpers are needed; docs-first is also OK — validate with a Tier-2 example.
Imports: prefer explicit registration APIs in docs for auditability; blank import as opt-in for discovery.
BYO-kit: document app + widget + contracts without core/* as a first-class path — especially for games / custom shells.

Summary

Lean kernel + independent Go modules + Obsidian-style index where proxy.golang.org / sumdb are the artifact and integrity layer — this is the right architecture for a trusted Pure Go widget ecosystem. It keeps ui compact, makes community growth opt-in, and turns "verified" into something CI can prove.

I'm +1 to treat this as the north star for extensibility up to v1.0 and validate it through examples/custom_widget/, ThemeBundle implementations, and 2–3 reference modules in the catalog.

Thank you for compiling this into a clear RFC — I strongly support the lean kernel + Obsidian-style catalog direction. In my view, this is not just a convenient distribution scheme, but a solid architectural plan for how the Pure Go GUI ecosystem should grow post-v1.0.

Why the Obsidian model fits GoGPU so well
Obsidian's community plugins have demonstrated a sound product principle: the platform owns the contracts and trust, authors own source code and release cycles, and the catalog is an index with gates, not a monorepo that sucks in every popular extension.

Mapping to VEE:

Aspect Obsidian GoGPU VEE
Stable platform App + plugin API L0 gogpu/ui (kernel + contracts + SDK facade)
Extension ownership Author's own GitHub repo L1 independent Go modules
Discoverability Community plugins browser L2 gogpu/widgets index
Quality / trust Review + listing rules Submit-gate CI + verified badges
Artifacts Plugin releases Go module proxy (proxy.golang.org) + integrity via sumdb
This separation directly addresses the risks outlined in the RFC:

The kernel does not become a warehouse. Charts, Markdown, CodeEditor, calendars, domain-specific kits, enterprise ThemeBundles stay outside ui. The kernel remains maintainable "forever."

Applications stay opt-in. The consumer pays only for what they explicitly require / import. Dead-code elimination stays honest — no fake "disable stock UI" toggle.

Maintenance scales. The organization reviews index entries and CI attestations, not every line of every community widget.

Authors move at their own pace. Semver tags, breaking changes, and experimental APIs live in L1 and do not block kernel releases.

This is exactly the model I had in mind when comparing to Obsidian: curated discoverability without the pressure of "everything in one tree" and without an untrusted zip-store.

Distribution via Go proxy — a key enhancement to the scheme
What makes this stronger than a typical plugin marketplace is that installation and integrity are already solved by Go's module system:

The catalog entry points to a module@version (the author's module).

The consumer installs with the standard toolchain: go get github.com/alice/ui-rating@v0.3.1.

Bytes come from proxy.golang.org (or from a private proxy in enterprise).

Integrity is pinned by sum.golang.org — retags / rewritten history do not pass silently.

The dependency graph is auditable: go list -m all, SBOM, reproducible builds.

Therefore, L2 should remain index-only: YAML entries, docs, schemas, badges, CI matrix. No vendoring of widget sources into gogpu/widgets. The catalog stays small and reviewable, and "verified" means attestation of compatibility with specific ui versions and platforms, not popularity.

The compile-time model is also better than runtime plugin downloading as the default for desktop GUI:

predictable binary contents;

no unexpected network fetches on startup;

clear license / supply-chain surface at build time;

WASM/RPC can be added later as a separate path (uiplugin), without breaking the main L1 scenario.

Why this is a good architectural plan (not just packaging)
The three layers correctly define boundaries of dependencies and trust:

L0 Kernel — primitives, stable contracts (widget, layout, theme, registry, plugin/cdk), reference ThemeBundle, TestKit/SDK facade. The inclusion criterion (≥70% of apps + perpetual support + not domain-specific) is a good heuristic, even if the threshold is refined later.

L1 Modules — the real extension surface. Same Widget type, no second API. ThemeBundles / painters / custom kits are published as ordinary modules.

L2 Catalog — the product-level wrapper for trust and discoverability without owning the code.

This aligns well with GoGPU's existing ecosystem pattern (gpucontext / gputypes as contracts, implementations separate): contracts and lean core first, then optional modules, then a curated index.

I also agree with the order of work in the RFC:

Lock down contracts / SDK golden path before v1.0

Polish ThemeBundle wiring so community themes become real

Stand up catalog CI and 2–3 reference L1 modules end-to-end

Keep WASM/RPC vocabulary additive; runtime — when concrete editor/IDE requirements emerge

Postpone extracting uicore until there is measurable pain — SceneCache has already reduced compile surface; don't over-split prematurely

On the open questions, my lean:

Where the kernel lives: start with gogpu/ui as L0; extract uicore only if download/compile cost for third-party authors genuinely hurts.

sdk/: a thin facade inside ui is fine if examples/custom_widget/ shows helpers are needed; docs-first is also OK — validate with a Tier-2 example.

Imports: prefer explicit registration APIs in docs for auditability; blank import as opt-in for discovery.

BYO-kit: document app + widget + contracts without core/* as a first-class path — especially for games / custom shells.

Summary
Lean kernel + independent Go modules + Obsidian-style index where proxy.golang.org / sumdb are the artifact and integrity layer — this is the right architecture for a trusted Pure Go widget ecosystem. It keeps ui compact, makes community growth opt-in, and turns "verified" into something CI can prove.

I'm +1 to treat this as the north star for extensibility up to v1.0 and validate it through examples/custom_widget/, ThemeBundle implementations, and 2–3 reference modules in the catalog.

1 reply

lkmavi Aug 24, 2026
Collaborator Author

@zloymelnik Appreciate the detailed +1 - especially the Obsidian mapping and the emphasis on Go’s module proxy as the
artifact/integrity layer.
That separation is the core of VEE for us:

L0 stays lean and forever-maintained
L1 owns source + release cadence
L2 reviews index entries + attestations, not every community line
You’re right that this is stronger than a typical plugin marketplace: install path is go get module@version, bytes come from
proxy.golang.org (or a private proxy), integrity is pinned by sumdb, and “verified” means CI compatibility — not popularity.
We’ll treat your leanings as consensus signals for the open questions (kernel in ui for now, thin sdk/, explicit
registration preferred, BYO-kit documented). Next up is validating the north star with examples/custom_widget/, ThemeBundle
work, and a small set of reference modules in the catalog (DatePicker / ColorPicker remain strong Phase B candidates).
Thanks for reinforcing this as architecture, not just packaging.

lkmavi · 2026-08-25T10:43:26Z

lkmavi
Aug 25, 2026
Collaborator Author

@kolkov @darkliquid I have carefully studied the investigations darkliquid/ironwail-go#17 and put together a preliminary ADR, I'm interested in your opinion (and the rest @zloymelnik , @AgentNemo00 )

ADR-070: Engine UI Embedding and VEE Validation (ironwail-go RESEARCH-0008)

Field	Value
Status	Proposed
Date	2026-08-25
Scope	Ecosystem — `gogpu`, `gg`, `gogpu/ui`, VEE (#468)
Related	Discussion #468, ironwail-go #17, ADR-034, ADR-036, ADR-057, ADR-065, ADR-067, ADR-069
Evidence	darkliquid — RESEARCH-0008 (v1–v3) + v4 follow-up (2026-08-21/22)

Context

The GoGPU org proposed Verified Extension Ecosystem (VEE) in discussion #468: a lean gogpu/ui kernel (L0), independent extension modules (L1), and an index-only CI-verified catalog gogpu/widgets (L2). The org explicitly invited real-world validation from engine and game clients.

darkliquid (ironwail-go — pure-Go Quake on gogpu/WebGPU) ran four experimental branches (v1–v4) porting hand-rolled menu/console/HUD UI onto gogpu/ui. The widget layer stabilized quickly; all churn occurred at the integration seam — how a host that owns its own frame loop composites UI over 3D content.

Approaches tested

Branch	Loop owner	UI → surface
v1	Engine	gg-canvas bridge inside `RenderFrame`
v2	`desktop.Run`	3D → offscreen `gpuview`; UI compositor on top
v3	Engine	CPU `gg.Context` + custom WGSL overlay blit
v4	Engine	CPU readback blit + public `MarkPreserveContent()`

Root finding (four data points)

gogpu/ui's first-class path is desktop.Run (whole-application ownership). There is no supported contract for: render my widget tree into a texture/surface I own, on my own loop, with a single swapchain submit owned by the host framework.

Each branch hand-built that seam. Failures included: framework fights (v1), Vulkan presentation crashes from texture/encoder lifetime (v2), reflection/unsafe on gogpu internals (v3), and mandatory CPU readback because GPU-direct flush races the shared encoder (v4).

Decision

We accept VEE as the north star for widget distribution and kernel boundaries, and add a parallel P0 track for engine/game embedding in gogpu + gg that VEE does not cover.

1. Adopt from VEE (confirmed by ironwail)

VEE principle	Verdict	Evidence
Lean kernel — no community widgets in `ui`	Accept	All four branches: zero `core/*` imports; BYO-kit works
L1 = compile-time `go get` modules	Accept	No runtime zip store needed for game HUD
L2 catalog = index + CI attestation, not source warehouse	Accept	Orthogonal to embedding; still valuable for widget authors
`sdk/` + Tier-2 custom widget path	Accept (extend scope)	Games use `WidgetBase`, not Painter-over-stock
Defer `uicore` extraction	Accept	Pain is compositing API, not module download size
WASM/RPC runtime as P3 (`uiplugin`)	Accept	ironwail needs WASM target, not WASM plugins
No stock-UI kill switch — opt-in via imports	Accept	Go DCE validated; matches Angular CDK-without-Material

2. Add to roadmap (gaps VEE does not address)

Priority	Item	Owner packages
P0	Standalone engine embedding contract — widget tree → caller-owned texture/surface on caller-owned loop; gogpu owns one submit per frame	`gogpu`, `gg`, `ui` docs + example
P0	Record-only GPU flush — gg records into host encoder; never `Finish()`/`Submit()`/retain cmdbufs across frame boundary	`gg`
P0	Public bitmap font / strike registration	`gg`, `ui`
P0	`DrawImageSrcRect` / `ImageRegionDrawer` on Canvas	`gg`
P1	Document dual integration paths: `desktop.Run` (desktop app) vs engine embed (game/3D)	`ui`, `gogpu`
P1	Document input split: poll (`app.Input()`) for gameplay + EventSource for UI shell	`gogpu`
P2	`Continuous` / `AlwaysDirty` widget mode for per-frame redraw workloads	`ui`
P2	Raw palette color escape for palette-indexed art (parallel to ThemeBundle)	`ui`, `gg`

3. Reject or defer

Proposal	Verdict	Reason
Per-app custom WGSL composite (v3)	Reject as norm	Enterprise stacks provide one official composite path
Reflection/`unsafe` on gogpu frame state (v3)	Reject	v4 replaced with public `MarkPreserveContent()`
`desktop.Run` + `gpuview` as default engine path (v2)	Reject for engines	Loop inversion, no WASM, GPU lifetime crashes
CPU readback as long-term solution (v4)	Reject as target	Accept as interim until record-only/offscreen path ships
Painter pattern as primary game UI abstraction	Defer	Custom `WidgetBase` + Canvas primitives validated instead

Enterprise references

How mature stacks solve the same problem:

Pattern	Reference	GoGPU analogue
App owns event/render loop	winit, GLFW, SDL3	Engine path (caller loop) — missing contract
Full-application UI host	Electron, Flutter `runApp`	`desktop.Run` — exists
Render UI to texture, host composites	Qt Quick RenderControl, Flutter Engine embed	Needed (P0)
Single queue submit per frame	Vulkan/Metal best practice, Unity/Unreal frame graph	gg `RenderDirect` must not second-submit shared encoder
Custom draw + atlas sub-rects	Flutter `Canvas.drawImageRect`, Skia, Dear ImGui	`DrawImageSrcRect` (P0)
Bitmap/strike fonts for games	BMFont, Unity Font atlas	Public font registration (P0)
Retained vs immediate invalidation	Flutter RepaintBoundary vs game HUD full redraw	SceneCache for desktop; `Continuous` mode for games (P2)
Driver/plugin model	`database/sql`, Angular CDK	VEE L0/L1/L2 — validated
Curated index, not monorepo	Obsidian community plugins, VS Code marketplace	`gogpu/widgets` L2 — validated

Consequences

Positive

VEE can proceed on SDK + catalog without blocking game clients.
ironwail-go provides an evidence-backed checklist instead of hypothetical requirements.
MarkPreserveContent() (ADR-067 family) is confirmed as the correct world-preserve public seam; symmetry needed on UI-render side.
Clear separation: widget distribution (VEE) vs compositing contract (this ADR).

Negative / costs

Pre-v1.0 work expands: embedding example + gg flush mode are kernel-adjacent, not catalog-only.
Two documented integration paths increase documentation and test matrix surface.
Record-only flush requires careful API design to avoid regressing g3d fullscreen-overlay and desktop.Run paths.

Risks if deferred

Every engine/game client reinvents v1–v4 seams (custom WGSL, CPU readback, internal poking).
Vulkan/Metal presentation failures recur wherever RenderDirect is used on host-owned frames.
VEE "BYO-kit" documentation over-promises desktop.Run for workloads that need engine embed.

Validation matrix (ironwail vs VEE claims)

Claim	v1	v2	v3	v4	Enterprise fit
BYO-kit (`app` + `widget`, no `core/*`)	✓	✓	✓	✓	Qt CDK, Bevy+egui
Custom widgets on `WidgetBase`	✓	✓	✓	✓	ImGui, CustomPainter
Painter over stock widgets	—	—	—	—	N/A for Quake UI
SceneCache / retained mode win	✗	✗	✗	✗ (full redraw)	Desktop apps only
ThemeBundle for palette art	✗	✗	✗	✗	Dual path needed
`desktop.Run` + gpuview	—	✓ (failed)	—	—	Electron-like, not engines
Engine-owned loop + WASM	✓	✗	✓	✓	winit pattern
GPU-direct composite	✗	✗ (crash)	✗	✗ (readback)	Single-submit rule
Public preserve seam	✗	partial	✗ (unsafe)	✓	g3d overlay pattern

Recommended next steps

examples/engine_overlay/ in gogpu or ui — minimal 3D stub + UI overlay, engine-owned loop, documented composite path (offscreen or record-only).
gg: implement record-only FlushGPUWithView mode (or offscreen composition owned by gogpu submit).
gg: DrawImageSrcRect + public bitmap font registration API.
ui: extend docs/EXTENSIONS.md with Desktop app vs Engine embed decision tree.
VEE Phase A+B continues in parallel — catalog does not replace embedding work.

Open questions

Should embedding contract live in gpucontext (like damage/compositor interfaces) or remain gogpu-specific?
Hard-fail vs report-only binary budget in catalog CI (VEE open question) — ironwail does not inform this.
Exact API for record-only flush: extend existing RenderDirect vs new RecordInto(encoder) entry point?
Should Continuous mode be a widget flag, a subtree policy, or an app-level app.WithRedrawPolicy()?

References

gogpu/gogpu #468 — VEE RFC
gogpu/gogpu #468 comment — darkliquid investigation link
darkliquid/ironwail-go #17 — RESEARCH-0008 (v1–v3)
darkliquid/ironwail-go #17 — v4 follow-up
gogpu: Context.MarkPreserveContent(), ContextRenderTarget.PreserveContent() (CHANGELOG, ADR-067 family)
g3d fullscreen-overlay example (gogpu-owned frame — reference implementation that works today)

0 replies

Navigation Menu

GoGPU

RFC: Verified Extension Ecosystem (VEE) — lean kernel, external modules, CI-verified catalog #468

Uh oh!

{{title}}

Uh oh!

Replies: 4 comments 8 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

GoGPU

RFC: Verified Extension Ecosystem (VEE) — lean kernel, external modules, CI-verified catalog #468

Uh oh!

lkmavi Aug 17, 2026 Collaborator

TL;DR

Context (what the RFC already got right)

Principles

Architecture: three layers

Core inclusion criterion

Stock widgets are optional — bring-your-own kit

Extension contracts (lock before v1.0)

1. SDK (sdk/)

2. Registry metadata (backward compatible)

3. widget.yaml (out-of-band)

4. ThemeBundle

5. Consumer UX

Catalog gogpu/widgets (L2)

Mental model: Obsidian-style catalog (index only)

CI as the trust product

Answers to the RFC open questions

Explicitly out of scope for phases A–C

Phased plan (refinement of the RFC timeline)

Governance (short)

Why this is enterprise-grade

Proposed decision

How to participate

Replies: 4 comments · 8 replies

Uh oh!

kolkov Aug 17, 2026 Maintainer

What we've studied

Topics that need discussion

1. Single module vs extraction — conflicting evidence, open question

2. Where does the "kernel" live and what exactly is it?

3. sdk/ — what, where, and how

4. ThemeBundle — interface exists, implementations needed

5. Catalog — interesting model, needs validation

6. WASM/RPC — analysis shows existing interfaces are sufficient

7. Extended registry metadata

What's clear vs what's open

Next steps we're considering

We'd value community input on

Uh oh!

kolkov Aug 17, 2026 Maintainer

Uh oh!

AgentNemo00 Aug 17, 2026

Uh oh!

kolkov Aug 17, 2026 Maintainer

Abandoned widget + old kernel version

Kernel backward compatibility

New version triggers re-verification

What happens with incompatible widgets

What makes this different from npm/crates.io

Uh oh!

AgentNemo00 Aug 17, 2026

Uh oh!

kolkov Aug 17, 2026 Maintainer

Uh oh!

darkliquid Aug 21, 2026

Uh oh!

zloymelnik Aug 24, 2026

Why the Obsidian model fits GoGPU so well

Distribution via Go proxy — a key enhancement to the scheme

Why this is a good architectural plan (not just packaging)

Summary

Uh oh!

lkmavi Aug 24, 2026 Collaborator Author

Uh oh!

lkmavi Aug 25, 2026 Collaborator Author

ADR-070: Engine UI Embedding and VEE Validation (ironwail-go RESEARCH-0008)

Context

Approaches tested

Root finding (four data points)

Decision

1. Adopt from VEE (confirmed by ironwail)

2. Add to roadmap (gaps VEE does not address)

3. Reject or defer

Enterprise references

Consequences

Positive

Negative / costs

lkmavi
Aug 17, 2026
Collaborator

1. SDK (`sdk/`)

3. `widget.yaml` (out-of-band)

Catalog `gogpu/widgets` (L2)

Replies: 4 comments 8 replies

kolkov
Aug 17, 2026
Maintainer

kolkov Aug 17, 2026
Maintainer

kolkov Aug 17, 2026
Maintainer

kolkov Aug 17, 2026
Maintainer

darkliquid
Aug 21, 2026

zloymelnik
Aug 24, 2026

lkmavi Aug 24, 2026
Collaborator Author

lkmavi
Aug 25, 2026
Collaborator Author