You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
External addon capabilities are projected through a fixed executable-config JSON schema and reconstructed into concrete proxy-type combinations. Each CSS or Go-block operation can create a temporary helper source tree and invoke go run. go list and go run are currently launched without context cancellation or deadlines.
Adding a new bridged capability requires coordinated changes to the public interface, wire schema, helper template, command dispatch, proxy types, loader switch, and registry metadata.
Problem
The public addon model is extensible through interfaces, but the executable bridge is a centrally closed protocol. Repeated helper compilation is expensive, capability evolution is brittle, and a hung Go tool or addon operation can block the calling command indefinitely.
Proposed direction
Define a versioned addon-host protocol with explicit capability descriptors and request/response envelopes. Compile or start one helper host per configuration/module digest and reuse it for the command lifetime. All operations should accept context.Context, support cancellation/deadlines, and return structured diagnostics.
Acceptance criteria
The bridge performs an explicit protocol-version handshake.
Addon capabilities are represented as versioned descriptors rather than concrete proxy-type combinations.
Unknown optional capabilities can be ignored safely; incompatible required capabilities produce a clear diagnostic.
One helper build/process is reused for repeated operations against the same configuration digest.
go list, helper build/start, and addon requests use exec.CommandContext or equivalent cancellation.
Configurable or documented deadlines exist for helper startup and requests.
Helper stderr, exit status, malformed responses, and timeouts become structured diagnostics without leaking secrets.
The protocol has payload-size limits and validates addon-generated relative file paths.
Tests cover version mismatch, unknown capability, timeout, cancellation, crash, malformed JSON, and repeated request reuse.
Addon reference documentation describes compatibility and process-lifecycle guarantees.
Affected areas
internal/project/config_exec.go, public addon contracts, addon registry metadata, CLI/dev cancellation paths.
Priority
Medium
Context
External addon capabilities are projected through a fixed executable-config JSON schema and reconstructed into concrete proxy-type combinations. Each CSS or Go-block operation can create a temporary helper source tree and invoke
go run.go listandgo runare currently launched without context cancellation or deadlines.Adding a new bridged capability requires coordinated changes to the public interface, wire schema, helper template, command dispatch, proxy types, loader switch, and registry metadata.
Problem
The public addon model is extensible through interfaces, but the executable bridge is a centrally closed protocol. Repeated helper compilation is expensive, capability evolution is brittle, and a hung Go tool or addon operation can block the calling command indefinitely.
Proposed direction
Define a versioned addon-host protocol with explicit capability descriptors and request/response envelopes. Compile or start one helper host per configuration/module digest and reuse it for the command lifetime. All operations should accept
context.Context, support cancellation/deadlines, and return structured diagnostics.Acceptance criteria
go list, helper build/start, and addon requests useexec.CommandContextor equivalent cancellation.Affected areas
internal/project/config_exec.go, public addon contracts, addon registry metadata, CLI/dev cancellation paths.