Namespace plugin APIs

When exposing data to the client, treat shared/global values and plugin routes as explicit API surface: 1) Don’t publish global client/window state by sprinkling ad-hoc dictionaries into multiple unrelated API handlers. Instead, use one centralized mechanism:

copy reviewer prompt

Prompt

Reviewer Prompt
Deploy Agent

When exposing data to the client, treat shared/global values and plugin routes as explicit API surface:

1) Don’t publish global client/window state by sprinkling ad-hoc dictionaries into multiple unrelated API handlers. Instead, use one centralized mechanism:

  • Inject into index.html (e.g., next to globalThis.gitinfo), or
  • Expose a dedicated “runtime info” endpoint with a stable contract.

Example (centralized injection):

<script>
  // after globalThis.gitinfo
  globalThis.runtimeInfo = {
    isDevelopment: 
  };
</script>

2) Plugin endpoints must be mounted under a stable namespace to prevent collisions with core API routes.

  • Route prefix rule: /plugins/<plugin_name>/...
  • Plugin modules should register their own endpoints under that prefix.

Example (route mounting concept):

# core router bootstrap
register_routes(prefix=f"/plugins/{plugin_name}", handlers=plugin_handlers)

Source discussions