diff --git a/.out-of-scope/codex-native-plugin-skips-preproposal.md b/.out-of-scope/codex-native-plugin-skips-preproposal.md new file mode 100644 index 000000000..f2e39e475 --- /dev/null +++ b/.out-of-scope/codex-native-plugin-skips-preproposal.md @@ -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 diff --git a/.out-of-scope/crush-runtime-in-core.md b/.out-of-scope/crush-runtime-in-core.md new file mode 100644 index 000000000..92c335255 --- /dev/null +++ b/.out-of-scope/crush-runtime-in-core.md @@ -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