From 77ff068cc3ff11fa41dfe469f579f2bc89e43446 Mon Sep 17 00:00:00 2001 From: Tom Boucher Date: Mon, 14 Sep 2026 19:58:38 -0400 Subject: [PATCH] docs(#4722): record Kiro and Zoo Code runtime requests as out-of-scope (#4750) * docs(#4722): record Kiro and Zoo Code runtime requests as out-of-scope Both #4722 and #4746 asked to add a new first-party, in-tree runtime (Kiro, Zoo Code). The repo's standing policy against expanding the in-tree runtime set already covers this shape of request (crush-runtime-in-core.md, omp-runtime-in-core.md); recording these two so the same asks aren't re-litigated from scratch next time they land. Co-Authored-By: Claude Sonnet 5 * docs(#4722): correct ADR-857 D8 status in the new out-of-scope entries Reviewer caught that the Re-open criteria section, inherited verbatim from the crush/omp sibling entries, claimed the ADR-857 D8 external capability loader "has not been delivered." ADR-1244 (Accepted, ratified 2026-07-17) explicitly states it delivers that exact gate for third-party role:"runtime" capabilities. Correct both new entries to reflect that the mechanism exists today, while keeping the in-tree non-acceptance verdict itself unchanged (a maintainer bandwidth/scope call, not a tooling gap). Co-Authored-By: Claude Sonnet 5 * docs(#4722): match the newer out-of-scope house format Orthogonal review (Standards axis) noted the two newest sibling KB entries (crush-runtime-in-core.md, codex-native-plugin-skips-preproposal.md) lead with a dedicated "## Policy (standing, not case-by-case)" section before "Proposal summary"; these two files folded the same claim into a bullet instead. Restructure to match, no content change beyond de-duplicating the policy statement out of the bullet list it was also stated in. Co-Authored-By: Claude Sonnet 5 --------- Co-authored-by: sim Co-authored-by: Claude Sonnet 5 --- .out-of-scope/kiro-runtime-in-core.md | 42 ++++++++++++++++++++++++++ .out-of-scope/zoo-runtime-in-core.md | 43 +++++++++++++++++++++++++++ 2 files changed, 85 insertions(+) create mode 100644 .out-of-scope/kiro-runtime-in-core.md create mode 100644 .out-of-scope/zoo-runtime-in-core.md diff --git a/.out-of-scope/kiro-runtime-in-core.md b/.out-of-scope/kiro-runtime-in-core.md new file mode 100644 index 000000000..4d94bc40f --- /dev/null +++ b/.out-of-scope/kiro-runtime-in-core.md @@ -0,0 +1,42 @@ +# Kiro (AWS) CLI + IDE as a first-class runtime in gsd-core + +**Source:** [#4722](https://github.com/open-gsd/gsd-core/issues/4722) +**Decision:** wontfix — No-go 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-09-14 + +## 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.** Same standing ground recorded in [`crush-runtime-in-core.md`](./crush-runtime-in-core.md) and [`omp-runtime-in-core.md`](./omp-runtime-in-core.md). The policy is explicitly host-agnostic: no Kiro-specific prior denial existed before this issue, but the standing decision text evaluates "does this ask for a new runtime or add-on in-tree," not "is this particular one well executed" — AWS backing does not change the maintenance-obligation calculus the policy is about. + +## Proposal summary + +#4722 asked to add `--kiro` as a new first-party, in-tree runtime integration for AWS's Kiro CLI + IDE — a new runtime descriptor and installer wiring, structurally the same shape as prior first-party-runtime requests. + +## 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. +- **`kiro` does not exist in `capabilities/` or `docs/registries/eos.json` today** (verified at triage time), so there is no existing partial support to build on that would change the calculus. + +## What this does NOT cover + +This entry denies **first-party, in-tree runtime registration for Kiro.** It does not deny, and must never be cited against: + +- **Shipping an out-of-tree host-plugin for Kiro**, via the Host-Integration SDK, listed in `docs/registries/eos.json` — same path as `gsd-cursor`/`gsd-omp`/`gsd-reasonix`. +- **Shipping Kiro as a third-party `role: "runtime"` capability via ADR-1244's external loader.** ADR-857 D8 deferred third-party CLI/runtime support "to an external loader + trust/validation gate"; ADR-1244 (Accepted, ratified 2026-07-17) is that ADR and delivers that gate — a third-party capability, including `role: "runtime"`, can be installed from outside gsd-core's own tree (`~/.gsd/capabilities//` global, or `.gsd/capabilities//` project-scoped) under its trust/consent model. This is a live mechanism today, not a future trigger — see "Re-open criteria" below. +- **A Kiro integration built as a Capability**, if what's actually needed is a toggleable feature rather than a new host identity. +- **Fixing defects that surface through a non-registered runtime**, or improving the documented override/SDK contracts a host plugin depends on. +- **Any existing runtime's support tier.** + +## Re-open criteria + +- **The ADR-857 D8 external-loader condition is already met** — ADR-1244 (Accepted 2026-07-17) delivers third-party `role: "runtime"` capability loading; this is no longer a future trigger. What remains unmet is a maintainer decision to expand gsd-core's own *first-party, in-tree* supported-runtime set specifically — that is a bandwidth/scope call, not a tooling gap, and reopens only if funded development changes the maintenance calculus described above. +- Kiro demonstrates an integration need the EoS Host-Integration Interface AND the ADR-1244 third-party capability loader genuinely cannot express (none shown to date). + +## Related + +- [`crush-runtime-in-core.md`](./crush-runtime-in-core.md) — sibling decision, same ground, same standing policy +- [`omp-runtime-in-core.md`](./omp-runtime-in-core.md) — sibling decision, same ground +- [`zoo-runtime-in-core.md`](./zoo-runtime-in-core.md) — sibling decision filed the same day, same ground +- [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 diff --git a/.out-of-scope/zoo-runtime-in-core.md b/.out-of-scope/zoo-runtime-in-core.md new file mode 100644 index 000000000..c6260c985 --- /dev/null +++ b/.out-of-scope/zoo-runtime-in-core.md @@ -0,0 +1,43 @@ +# Zoo Code (successor of archived Roo Code) as a first-class runtime in gsd-core + +**Source:** [#4746](https://github.com/open-gsd/gsd-core/issues/4746) +**Decision:** wontfix — No-go 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-09-14 + +## 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.** This is the same standing ground already recorded twice: [`crush-runtime-in-core.md`](./crush-runtime-in-core.md) and [`omp-runtime-in-core.md`](./omp-runtime-in-core.md). The standing decision text is direct: evaluate "does this ask for a new runtime or add-on in-tree," not "is this particular one well executed." Nothing about Zoo's specific quality, research depth, or the reporter's cited working private-fork port changes this — the same class of well-executed prior asks (crush, OMP, Reasonix) were declined on identical grounds. + +## Proposal summary + +#4746 asked to add `zoo` (Zoo Code, the VS Code extension community continuation of the archived Roo Code) as a **first-party, in-tree** tier-2 runtime: a `capabilities/zoo/capability.json` descriptor, alias canonicalization (`roo`, `roo-code`, `roo-cline`, `zoo-code` → `zoo`), and a new dedicated `zoo-modes` install-surface writer to merge GSD agents into Zoo's single-file `.roomodes`/`custom_modes.yaml` custom-mode format (following the `cline-rules` precedent for merge-into-one-file surfaces). The proposal included extensive docs-verified integration facts (schema, tool names, subagent dispatch semantics, globalStorage paths) and cited a working private-fork port (`harmony-ai-solutions/gsd-roo-code`). + +## 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. +- **Neither `zoo` nor `roo` exists in `capabilities/` or `docs/registries/eos.json` today** (verified at triage time), so there is no existing partial support to build on that would change the calculus. + +## What this does NOT cover + +This entry denies **first-party, in-tree runtime registration for Zoo Code.** It does not deny, and must never be cited against: + +- **Shipping an out-of-tree host-plugin for Zoo Code.** This is welcome and supported, and is the intended route — a Zoo plugin that embeds GSD via the Host-Integration SDK and is listed in `docs/registries/eos.json`, same as `gsd-cursor`/`gsd-omp`/`gsd-reasonix`. The reporter's own docs-verified integration research (custom-modes schema, `.roo/commands/` layout, `new_task` subagent dispatch) is directly reusable there without any gsd-core change. +- **Shipping Zoo as a third-party `role: "runtime"` capability via ADR-1244's external loader.** ADR-857 D8 deferred third-party CLI/runtime support "to an external loader + trust/validation gate"; ADR-1244 (Accepted, ratified 2026-07-17) is that ADR and delivers that gate — a third-party capability, including `role: "runtime"`, can be installed from outside gsd-core's own tree (`~/.gsd/capabilities//` global, or `.gsd/capabilities//` project-scoped) under its trust/consent model. This is a live mechanism today, not a future trigger — see "Re-open criteria" below. +- **A Zoo integration built as a Capability**, if what's actually needed is a toggleable feature rather than a new host identity. +- **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.** +- **Any existing runtime's support tier**, including the unrelated existing `cline` runtime this proposal modeled its shape on. + +## Re-open criteria + +- **The ADR-857 D8 external-loader condition is already met** — ADR-1244 (Accepted 2026-07-17) delivers third-party `role: "runtime"` capability loading; this is no longer a future trigger. What remains unmet is a maintainer decision to expand gsd-core's own *first-party, in-tree* supported-runtime set specifically — that is a bandwidth/scope call, not a tooling gap, and reopens only if funded development changes the maintenance calculus described above. +- Zoo Code demonstrates an integration need the EoS Host-Integration Interface AND the ADR-1244 third-party capability loader genuinely cannot express (none shown to date). + +## Related + +- [`crush-runtime-in-core.md`](./crush-runtime-in-core.md) — sibling decision, same ground, same standing policy +- [`omp-runtime-in-core.md`](./omp-runtime-in-core.md) — sibling decision, same ground +- [`kiro-runtime-in-core.md`](./kiro-runtime-in-core.md) — sibling decision filed the same day, same ground +- [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