#1365 Collective management API for extension-based automation

Request

Expose a REST API (with OpenAPI spec) for managing swamp-club collectives programmatically. The goal is building a swamp model extension (@webframp/swamp-club or similar) that manages collective membership, settings, and extension inventory — swamp managing swamp.

Use Case

As a collective owner with multiple team members and published extensions, I want to:

1. List collective members — who has access, what roles
2. Add/remove members — invite by username/email, assign roles
3. List collective extensions — published packages, versions, download counts
4. Manage extension settings — deprecate, transfer ownership, update metadata
5. Audit — who published what, when, activity log

All of this stored as swamp data (versioned, queryable via CEL), so I can build workflows around collective governance — approval gates for new members, automated extension audits, onboarding workflows.

Current State — Technical Findings

Probed the swamp-club.com API surface with an authenticated bearer token:

Stub/placeholder routes (200 but no real data)

• GET /api/collectives → Hello, Collectives!
• GET /api/me → Hello, Me!
• GET /api/user → Hello, User!
• GET /api/account → Hello, Account!
• GET /api/organizations → Hello, Organizations!
• GET /api/teams → Hello, Teams!
• GET /api/extensions?collective=webframp → Hello, Extensions!
• GET /api/openapi.json → Hello, Openapi.json!
• GET /api/swagger.json → Hello, Swagger.json!
• GET /api/docs → Hello, Docs!

404 routes (no endpoint at all)

• GET /api/v1/collectives
• GET /api/collectives/webframp
• GET /api/orgs/webframp
• GET /api/collective/webframp/members
• GET /api/extensions/search?q=webframp
• GET /api/extensions/@webframp/dynamodb-datastore

What works via the CLI but has no discoverable HTTP API

• swamp auth whoami --json returns collective membership
• swamp extension search/info/push operates on extensions
• These likely use an internal RPC protocol or a non-public API hostname

Conclusion

The extension registry's data operations (search, info, push, pull) appear to use a mechanism not exposed as a standard REST API. The /api/* routes are placeholder stubs. There's no public OpenAPI spec, no functional collective management endpoints, and no way to programmatically manage membership or settings beyond what the CLI provides.

Desired API Surface

At minimum:

• GET /api/collectives/:name — collective details
• GET /api/collectives/:name/members — list members with roles
• POST /api/collectives/:name/members — invite/add member
• DELETE /api/collectives/:name/members/:userId — remove member
• GET /api/collectives/:name/extensions — list published extensions
• PATCH /api/collectives/:name — update collective settings
• GET /api/openapi.json — machine-readable spec for all the above

Authentication via existing bearer token from swamp auth login.

Why This Matters

Without a management API, collective administration requires manual web UI interaction — which means it can't be automated, audited, or governed via the same swamp primitives that manage everything else. The meta-use-case (swamp managing swamp) is a strong proof point for the platform.