Skip to content

Resource variable exports are not discoverable through the CLI #6

Description

@jeroenrinzema

Managed resources export their connection details as variables that an App's environment can reference — ${db.uri}, ${db.password}, ${cache.uri} and so on. This is documented at resources/postgres and resources/valkey, and it is the intended way to wire an app to a database.

None of it is reachable from the CLI. There is no command, schema field, or API response that tells you these variables exist or what they are called.

What I checked (CLI 0.1.0)

Route Result
brainpod describe resource Postgres Only diskRef, instance, version — the input schema. No exports.
brainpod describe resource App spec.env is {name, value} with value: minLength 1. Nothing indicates value may be a reference.
GET /v1/openapi.json 18 paths, none for variables. No exports/variables vocabulary anywhere in the document.
GET /v1/pods/{pod}/resources/{kind}/{namespace}/{name} Resource is urn + content, i.e. the spec you submitted, returned back. No status or exports section.
brainpod blueprint get wordpress Body says "Database credentials are wired automatically", but defaults is {} and the resource graph is not returned, so the syntax never appears.

The only way to discover the syntax through the CLI is to install a blueprint onto a pod and read the resulting App's env back — mutating a draft in order to learn a notation.

Why it matters

Driving the CLI from a coding agent is a documented onboarding path, and describe is explicitly positioned as the authoritative contract for each kind. An agent that reads describe resource Postgres, finds no exports, and reads describe resource App, finding value is a plain string, will reasonably conclude that every value must be literal. It then tries to hand-assemble a connection string using a password that is generated by the platform and never exposed — so it either stalls or ships a broken DATABASE_URL.

Suggestions

  • Add an exports (or variables) section per kind to brainpod describe resource <kind>, and to the OpenAPI document it is derived from, listing the available fields and their meaning.
  • Note in describe resource App that spec.env[].value accepts ${<resource>.<field>} references, with a pointer to where the per-kind fields are listed.
  • Consider surfacing the resolved set for a pod, e.g. brainpod --pod <pod> resource variables, so an agent can confirm a reference before composing a draft.

Related

brainpodnl/skills#6 — the deploy skill currently tells agents that these exports do not exist, partly because describe gives it no reason to think otherwise.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions