Marketplace dependency management: depend on other projects, external APIs, and platform infrastructure

[kaje94]

Marketplace dependency management — depend on other projects, external APIs, and platform infrastructure

This PR lets a project declare a dependency, resolve it from the architecture view, and have the platform provision/wire it all the way through to a running deployment — no hand-editing of YAML, connection strings, or secrets. It builds on the earlier marketplace work already on cloud-test (a project can model dependencies and consume another project's public service). 60 commits.

A component can now depend on three kinds of thing, and each follows the same lifecycle — discover → resolve → provision/wire → inject as runtime config:

1. Another project's service

The architect discovers services published across the org. If the target is exposed project-only, the consumer can request access from its own design view: this opens a task + GitHub issue on the provider's repo; on grant, the platform publishes the endpoint, closes the issue, and records the grant durably (exposesAPI.orgPublished). The cross-project URL is then resolved and injected into the consumer.

2. An external API

The architect discovers the API via a web_search tool and flags whether it needs an OpenAPI contract. The BFF fetches (SSRF-hardened), validates, normalizes, and stores that spec inside the consumer's repo, and the coding agent implements the client against that exact contract. The API key is entered once in the drawer, stored as a secret, and injected by name only.

3. Platform-provisioned infrastructure (e.g. a database)

The architect discovers what the platform can provision (a read-only catalog over ClusterResourceTypes) and emits a platform-resource dependency. Provisioning goes through a narrow provisioner seam — an OC-native path (built now, with a sample CloudNativePG Postgres) behind an interface a future cloud provisioning-API can swap in. Provisioning is asynchronous: the BFF authors the OC Resource + per-env ResourceReleaseBinding, a watcher completes the task when the binding reports Ready, then the connection details (<DEP>_HOST/PORT/DBNAME/USER/PASSWORD) are wired into the consumer's workload.yaml — secret values via secretKeyRef, never in the diff. Credentials can be rotated (re-provision), and deleting the project tears the database down instead of orphaning it.

One place to resolve everything — the dependency drawer

All resolution (pick-a-candidate / provide-a-spec / request-access / provision), plus per-environment value entry and secret rotation, now live in a single side drawer on the architecture page. The standalone Dependencies tab is retired. The same drawer opens in place from the tasks board when a task is waiting on a value or a provision.

Lifecycle correctness

• Proceed-gate: draft autosave is always allowed, but save-and-proceed returns 409 while any dependency is unresolved / blocked / ambiguous — so a design can't advance to tasks with a dangling dependency.
• Tasks board: on-hold tasks explain why they're waiting, and platform (SYSTEM) tasks surface a Provision / Provide configuration CTA that opens the drawer; deployed platform tasks move to Done; a board-split race that could hide a task is fixed.
• Cleaner starting point: the requirements sketch preserves user-stated external systems (a real DB, an org service, an external API) instead of collapsing them into a self-contained app; the Go skill defaults persistence to a platform-provisioned database rather than embedded SQLite.

Verification

The external-API and platform-database chains are both verified live end-to-end on the local cluster:

• External API: web_search discovery → spec stored in-repo (survives the tagged save) → 409 proceed-gate → agent implements against the stored contract → merge → build → deploy → live GET /weather?city=London returns real data → secret rotation verified (replace → ESO re-sync → restart → still serves).
• Platform database: provision → CNPG Postgres reaches Ready → task completes → consumer wired → agent deploys → live POST /orders persists + psql confirms rows in the real Postgres, order total converted via the wired external rate API. Full Go suite + console build/tests green.

Security

The SSRF-guarded spec fetch received a platform-design-expert review: TOCTOU-safe single DNS resolution, https-only, IP denylist (incl. CGNAT / NAT64 64:ff9b::/96), !IsGlobalUnicast() gate, redirect + size/timeout caps, resolved IP dropped from errors, and a YAML alias-bomb regression test.

Notes

• Marketplace design docs under docs/design/marketplace/ are gitignored and not in this PR.
• deployments/docker-compose.yml's local AGENT_RUNNER_IMAGE override is intentionally not committed (local-dev workaround).

🤖 Generated with Claude Code