Decompose #18 — plugin API for gates into 4 phases #22

New issue

Closed

opened 2026-05-13 23:44:28 +00:00 by Mark · 1 comment

Mark commented

2026-05-13 23:44:28 +00:00

Owner

Goal

Break down GSD2_agent#18 (No plugin API for custom gate types) into independently implementable phases.

Decomposition

Gates are hardcoded with no plugin system for custom gate types. Split into phases:

Phase 1 — Gate Interface & Registry

Define Gate interface: name, dependencies: List[GateRef], run(context: GateContext) -> GateResult, isCacheable: Boolean
Create GateRegistry — maps gate names to implementations, supports registration at import time
Refactor existing hardcoded gates (implement, verify, commit, etc.) to implement the Gate interface and self-register
No behavioral change — all existing gates still run identically, just now through the registry

Phase 2 — Gate Discovery (File-System)

Scan a configured directory (.gsd/gates/ or $PROJECT/.gsd/plugins/gates/) for Python files
Import discovered modules, which call GateRegistry.register() at module level
Config: gate_plugin_dirs: List[str] in GSD config
Error handling: bad plugin doesn't crash the pipeline (skip + warn)

Phase 3 — Gate Definition Format (YAML/JSON)

Support defining gates declaratively without Python code:
YAML gate definitions: name, script path, dependencies, cache key template, env vars
Simple shell-command gates: gate: "run: ./scripts/deploy.sh" with if exit_code != 0: fail
Template-based gates that compose existing gates

Phase 4 — Documentation & Examples

Write plugin authoring guide
Ship 2-3 example custom gates (e.g., security-scan, docker-build, notify-slack)
Example in a .gsd/gates/examples/ directory
CLI commands: gsd gates list, gsd gates info <name>, gsd gates validate <path>

Dependency Graph

Phase 1 (Interface + Registry) -> Phase 2 (Discovery) -> Phase 3 (YAML Gates) -> Phase 4 (Docs + Examples)

Each phase ships independently. Phase 1 alone makes the codebase cleaner even without custom gates. Phases 2-3 add the actual extensibility.

## Goal Break down GSD2_agent#18 (No plugin API for custom gate types) into independently implementable phases. ## Decomposition Gates are hardcoded with no plugin system for custom gate types. Split into phases: ### Phase 1 — Gate Interface & Registry - Define `Gate` interface: `name`, `dependencies: List[GateRef]`, `run(context: GateContext) -> GateResult`, `isCacheable: Boolean` - Create `GateRegistry` — maps gate names to implementations, supports registration at import time - Refactor existing hardcoded gates (implement, verify, commit, etc.) to implement the `Gate` interface and self-register - **No behavioral change** — all existing gates still run identically, just now through the registry ### Phase 2 — Gate Discovery (File-System) - Scan a configured directory (`.gsd/gates/` or `$PROJECT/.gsd/plugins/gates/`) for Python files - Import discovered modules, which call `GateRegistry.register()` at module level - Config: `gate_plugin_dirs: List[str]` in GSD config - Error handling: bad plugin doesn't crash the pipeline (skip + warn) ### Phase 3 — Gate Definition Format (YAML/JSON) - Support defining gates declaratively without Python code: - YAML gate definitions: name, script path, dependencies, cache key template, env vars - Simple shell-command gates: `gate: "run: ./scripts/deploy.sh"` with `if exit_code != 0: fail` - Template-based gates that compose existing gates ### Phase 4 — Documentation & Examples - Write plugin authoring guide - Ship 2-3 example custom gates (e.g., `security-scan`, `docker-build`, `notify-slack`) - Example in a `.gsd/gates/examples/` directory - CLI commands: `gsd gates list`, `gsd gates info <name>`, `gsd gates validate <path>` ## Dependency Graph Phase 1 (Interface + Registry) -> Phase 2 (Discovery) -> Phase 3 (YAML Gates) -> Phase 4 (Docs + Examples) Each phase ships independently. Phase 1 alone makes the codebase cleaner even without custom gates. Phases 2-3 add the actual extensibility.

Mark added the

feature-request

triage-approved

labels

2026-05-13 23:44:28 +00:00

Mark referenced this issue

2026-05-13 23:44:28 +00:00

No plugin system for custom gates #18

Mark added

triage-approved

and removed

triage-approved

feature-request

labels

2026-05-14 04:02:05 +00:00

Mark referenced this issue from a commit

2026-05-14 18:56:52 +00:00

feat: implement Decompose #18 — plugin API for gates into 4 phases

Mark closed this issue

2026-05-14 18:56:52 +00:00

Mark commented

2026-05-14 18:57:00 +00:00

Author

Owner

Implemented and closed via commit 4289891c.

Implementation: Plugin gate API with 4 decomposition phases — gate interface types, gate registry, gate execution engine, and gate integration hooks. Also added .gsd/ to .gitignore to fix tracked runtime state file conflicts.

Implemented and closed via commit 4289891c. Implementation: Plugin gate API with 4 decomposition phases — gate interface types, gate registry, gate execution engine, and gate integration hooks. Also added .gsd/ to .gitignore to fix tracked runtime state file conflicts.