Records two triage dispositions from the 2026-08-29 /triage-review sweep: new runtimes and first-party add-ons are not accepted in-tree; both route to the EoS Registry or Capability system as community-maintained work. Closes #4027 Closes #4033 Co-authored-by: sim <sim@local>
This commit is contained in:
Tom Boucher
90
.out-of-scope/codex-native-plugin-skips-preproposal.md
Normal file
90
.out-of-scope/codex-native-plugin-skips-preproposal.md
Normal file
@@ -0,0 +1,90 @@
|
||||
# Codex-native GSD plugin, filed without a pre-proposal
|
||||
|
||||
**Source:** [#4027](https://github.com/open-gsd/gsd-core/issues/4027)
|
||||
**Decision:** wontfix — No-go as filed; redirected to community-maintained distribution (EoS/Capability), not a first-party plugin
|
||||
**Date:** 2026-08-29
|
||||
|
||||
## Policy (standing, not case-by-case)
|
||||
|
||||
**GSD is not accepting new add-ons as first-party, maintainer-owned work at this
|
||||
time — full stop.** A "plugin" proposal that asks gsd-core to own, package, and
|
||||
maintain a new distribution surface is declined regardless of how well-executed
|
||||
the implementation is; the supported path is community-maintained distribution
|
||||
through the EoS Registry or the Capability system, where the author owns the
|
||||
release cadence and maintenance. This is the same ground as new-runtime
|
||||
requests (see [`crush-runtime-in-core.md`](./crush-runtime-in-core.md)) applied
|
||||
to add-ons generally, not just runtimes. A future triage pass should apply this
|
||||
without re-litigating whether a particular plugin proposal is good — the
|
||||
question is only "is this asking gsd-core to own a new add-on," not "is the
|
||||
pre-proposal filed."
|
||||
|
||||
## Proposal summary
|
||||
|
||||
#4027 proposes an "official-format local Codex plugin" packaging GSD's existing
|
||||
skills and MCP server: a read-only project control center (milestone/phase/plan/
|
||||
verification/blocker status), a UAT workbench (review outstanding checks, record
|
||||
pass/issue results), and structured MCP output for non-visual clients. It claims
|
||||
to reuse the existing CLI, stdio MCP server, resource catalog, and npm package
|
||||
with no new runtime dependency, hosted backend, duplicate command layer, or
|
||||
persistent marketplace config. A working implementation allegedly exists on the
|
||||
reporter's own fork branch (`yansigit/gsd-core:codex/gsd-codex-plugin`); the
|
||||
reporter offered to open a PR against the feature template if approved.
|
||||
|
||||
## Why GSD does not own this — as filed
|
||||
|
||||
- **This repo has an established pre-proposal convention for first-party
|
||||
plugin/marketplace-surface work that this issue skipped entirely.** The
|
||||
precedent is `docs/proposals/mempalace-capability-prd-adr.md` — a status
|
||||
ladder (Pre-Proposal → Proposed → Accepted) for exactly this class of change:
|
||||
a new first-party distribution surface, not an ordinary feature. #4027 went
|
||||
straight to a `needs-triage` feature request backed by an already-built fork
|
||||
implementation, bypassing the step where the surface itself (not just the
|
||||
implementation) gets scoped and agreed.
|
||||
- **It lands on a design axis [ADR-857](../docs/adr/857-capability-system.md)
|
||||
explicitly defers** — the "third-party trust gate" / Connected Capability
|
||||
question (`docs/adr/857-capability-system.md:114`). Shipping a first-party
|
||||
plugin/marketplace surface now would build ahead of an unsettled architecture
|
||||
decision, independent of whether the reporter's implementation is good.
|
||||
- **The proposal is also under-specified for review as filed.** "Control
|
||||
center" and "UAT workbench" describe a shape, not an exact surface (which MCP
|
||||
tools, which resources, what the plugin manifest actually declares) — a
|
||||
pre-proposal doc is where that gets nailed down before a maintainer commits to
|
||||
an ongoing packaging/maintenance obligation.
|
||||
|
||||
## What this does NOT cover
|
||||
|
||||
This entry denies **gsd-core adopting this as first-party, maintainer-owned
|
||||
work.** It does not deny, and must never be cited against:
|
||||
|
||||
- **Shipping this as a community-maintained EoS host-plugin or Capability.**
|
||||
Everything the proposal describes (control-center views, UAT workbench, MCP
|
||||
output) can be built and distributed by the reporter today via the same path
|
||||
as `gsd-cursor`/`gsd-omp`/`gsd-reasonix`, listed in the EoS Registry — with no
|
||||
gsd-core changes and no maintainer packaging commitment.
|
||||
- **The underlying idea of packaging GSD for Codex.** No judgment is made on
|
||||
whether the idea is good — only that gsd-core will not be the one building,
|
||||
packaging, and maintaining it.
|
||||
- **The reporter's fork implementation itself**, which was not reviewed as part
|
||||
of this decision (reviewing an external fork's code is out of scope for
|
||||
triage; see the repo's untrusted-content handling).
|
||||
- **Existing Codex runtime support** (`capabilities/codex/capability.json`),
|
||||
which is unaffected.
|
||||
|
||||
## Re-open criteria
|
||||
|
||||
- GSD reopens accepting new first-party add-ons/plugins in general (a policy
|
||||
change, not a per-proposal argument) — until then, this and every similar
|
||||
"build/own X as a first-party plugin" request gets the same answer.
|
||||
- Separately, and only if that policy changes: a pre-proposal doc filed under
|
||||
`docs/proposals/` scoping the plugin's exact surface, following the
|
||||
Pre-Proposal → Proposed → Accepted ladder, and ADR-857's deferred third-party
|
||||
trust gate resolved.
|
||||
|
||||
## Related
|
||||
|
||||
- [ADR-857](../docs/adr/857-capability-system.md) — capability system, deferred
|
||||
third-party trust gate
|
||||
- `docs/proposals/mempalace-capability-prd-adr.md` — the precedent for this
|
||||
proposal class and its status ladder
|
||||
- `capabilities/codex/capability.json` — existing Codex runtime support,
|
||||
unaffected by this decision
|
||||
109
.out-of-scope/crush-runtime-in-core.md
Normal file
109
.out-of-scope/crush-runtime-in-core.md
Normal file
@@ -0,0 +1,109 @@
|
||||
# crush as a first-class in-tree registry entry
|
||||
|
||||
**Source:** [#4033](https://github.com/open-gsd/gsd-core/issues/4033)
|
||||
**Decision:** wontfix — closed as filed; redirected to the EoS Registry / out-of-tree host-plugin path (or a Capability, if the actual need turns out to be feature-shaped rather than runtime-shaped)
|
||||
**Date:** 2026-08-29
|
||||
|
||||
## Policy (standing, not case-by-case)
|
||||
|
||||
**GSD is not accepting new runtimes or add-ons as first-party, in-tree work at
|
||||
this time — full stop, not a "go-with-conditions" case-by-case call.** Any "add
|
||||
X to GSD" request for a new runtime, host integration, or add-on that is not
|
||||
already community-maintained gets the same disposition: redirect to the EoS
|
||||
Registry (new host/runtime identity) or the Capability system (new toggleable
|
||||
feature), never conditional approval into gsd-core itself. A future triage pass
|
||||
must not re-litigate this per-request — the diligence to apply is "does this
|
||||
ask for a new runtime or add-on in-tree", not "is this particular one well
|
||||
executed."
|
||||
|
||||
## Proposal summary
|
||||
|
||||
#4033 asked to add `crush` (Charm's terminal AI coding agent) as a **first-party,
|
||||
in-tree** runtime: a `capabilities/crush/capability.json` descriptor plus wiring
|
||||
across `runtimeTierDefaults` in `gsd-core/bin/shared/model-catalog.json`,
|
||||
`src/runtime-name-policy.cts`, `src/runtime-artifact-layout.cts`,
|
||||
`src/runtime-artifact-conversion.cts`, and `bin/install.js`, following `zcode` as
|
||||
the reference runtime. The reporter explicitly flagged five open questions about
|
||||
crush's agent-artifact format, permission model, frontmatter tolerance, MCP
|
||||
support, and install-scope conventions that could not be answered from inside
|
||||
gsd-core alone.
|
||||
|
||||
This is the same shape of ask as the Reasonix and OMP requests: a
|
||||
previously-unsupported host proposed as a new entry in the in-tree runtime
|
||||
registry GSD maintains itself.
|
||||
|
||||
## Why GSD does not own this
|
||||
|
||||
- **GSD is not expanding its in-tree supported-runtime set.** Each first-class
|
||||
runtime is a permanent maintenance obligation across the registry, installer,
|
||||
artifact conversion, agent discovery, model routing, dispatch isolation,
|
||||
golden install-parity fixtures, and localized capability matrices — carried
|
||||
indefinitely for a host GSD does not control. This is the same ground already
|
||||
recorded twice: [`omp-runtime-in-core.md`](./omp-runtime-in-core.md) and
|
||||
[`eos-registry-not-in-tree-runtime.md`](./eos-registry-not-in-tree-runtime.md).
|
||||
- **The supported direction is the Embeddable Orchestration System (EoS), and it
|
||||
is already available.** [ADR-1239](../docs/adr/1239-gsd-embeddable-orchestration-engine.md)
|
||||
exists precisely so a host embeds GSD through a stable negotiated interface and
|
||||
a thin host-plugin authored against the published Host-Integration SDK
|
||||
([`docs/how-to/author-a-host-plugin.md`](../docs/how-to/author-a-host-plugin.md))
|
||||
— without modifying gsd-core source. New hosts are listed in the
|
||||
[EoS Registry](../docs/registries/eos-registry.md) (`docs/registries/eos.json`,
|
||||
`type: "eos"`), via a docs PR (`npm run gen:registry`). Existing entries
|
||||
(`gsd-cursor`, `gsd-omp`, `gsd-reasonix`) already follow this path. If the
|
||||
actual need is narrower — a loop-behavior addition rather than a whole new
|
||||
host — the [Capability](../docs/how-to/develop-a-capability.md) path
|
||||
(`role: "feature"`, ADR-1244) is the other supported out-of-tree route; which
|
||||
one fits depends on what crush support actually turns out to require.
|
||||
- **Two directly-analogous precedents are on point and recent.** Reasonix
|
||||
(#3346, 2026-08-11) and OMP (#3037/#874/#1948, most recently 2026-06-08) were
|
||||
both declined on this exact ground — new terminal coding agent, proposed as an
|
||||
in-tree runtime — with the same redirect. The reviewer's own maturity research
|
||||
(crush's actual agent-config format is plain context files + a Bash-DSL
|
||||
config, not the MD+frontmatter the issue assumed; permission-model and MCP
|
||||
support unconfirmed) independently reinforces why this shouldn't be built
|
||||
in-tree against unverified assumptions about crush's real interface.
|
||||
|
||||
## What this does NOT cover
|
||||
|
||||
This entry denies **first-party, in-tree runtime registration for crush.** It
|
||||
does not deny, and must never be cited against:
|
||||
|
||||
- **Shipping an out-of-tree host-plugin for crush.** This is welcome and
|
||||
supported, and is the intended route. A crush plugin that embeds GSD via the
|
||||
Host-Integration SDK and is listed in `docs/registries/eos.json` is exactly
|
||||
the path this decision points to.
|
||||
- **A crush integration built as a Capability**, if what's actually needed is a
|
||||
toggleable feature rather than a new host identity — see
|
||||
[`docs/how-to/develop-a-capability.md`](../docs/how-to/develop-a-capability.md).
|
||||
- **Fixing defects that surface through a non-registered runtime**, or improving
|
||||
the documented override/SDK contracts a host plugin depends on.
|
||||
- **Migrations of already-supported runtimes** onto the EoS architecture. Those
|
||||
are lower-risk upgrades of hosts GSD already owns, not new-host onboardings.
|
||||
- **Any existing runtime's support tier.**
|
||||
|
||||
## Re-open criteria
|
||||
|
||||
- GSD reopens first-class in-tree runtime registration — e.g. funded development
|
||||
changes the maintenance calculus, or third-party `role: "runtime"` descriptors
|
||||
become loadable from outside the repo (ADR-857 D8's deferred purely-additive
|
||||
external loader). Until one of these holds, the answer for any new host is the
|
||||
EoS Registry, not the in-tree registry.
|
||||
- crush demonstrates an integration need the EoS Host-Integration Interface
|
||||
genuinely cannot express (none shown to date).
|
||||
|
||||
## Related
|
||||
|
||||
- [`omp-runtime-in-core.md`](./omp-runtime-in-core.md) — sibling decision, same
|
||||
ground
|
||||
- [`eos-registry-not-in-tree-runtime.md`](./eos-registry-not-in-tree-runtime.md) —
|
||||
sibling decision (Reasonix), same ground, same redirect
|
||||
- [ADR-1239](../docs/adr/1239-gsd-embeddable-orchestration-engine.md) — GSD as
|
||||
an Embeddable Orchestration Engine (EoS)
|
||||
- [`docs/how-to/author-a-host-plugin.md`](../docs/how-to/author-a-host-plugin.md) —
|
||||
the supported out-of-tree authoring path
|
||||
- [`docs/how-to/develop-a-capability.md`](../docs/how-to/develop-a-capability.md) —
|
||||
the Capability path, if the need turns out to be feature-shaped
|
||||
- [`docs/registries/README.md`](../docs/registries/README.md) — EoS Registry
|
||||
entry schema + submission process
|
||||
- [#2170](https://github.com/open-gsd/gsd-core/issues/2170) — Devin CLI runtime,
|
||||
the original on-point precedent cited by the Reasonix decision
|
||||
Reference in New Issue
Block a user