[subtask] [Subtask 1/4] Design CRD schemas for Wassette Kubernetes operator

[github-actions]

Parent Issue: #20

Objective

Design and document the Custom Resource Definition (CRD) schemas that will represent WebAssembly component tools in Kubernetes for the Wassette operator.

Context

The Wassette Kubernetes operator will manage WebAssembly components as Kubernetes resources. Before implementing the operator, we need well-designed CRD schemas that:

• Represent component metadata (name, OCI reference, version)
• Include permission/policy specifications
• Handle component lifecycle states
• Support dynamic loading and routing requirements

This subtask focuses on the design phase - creating the schema specifications that will guide the operator implementation.

Implementation Details

1. CRD Schema Design

Create CRD schemas for the following resources:

• WassetteComponent: Represents a single WebAssembly component

  • Spec fields: ociRef (OCI artifact reference), policy (permission policy), version, enabled
  • Status fields: state (loading/ready/failed), toolsExposed (list of available tools), lastLoaded

• WassettePolicy (optional): Reusable policy definitions

  • Allow referencing existing policy configurations from Proposal: Headless Deployment Mode for Wassette #307 (headless deployment mode)
  • Map to existing policy.yaml format used by Wassette

2. Integration Points

• Reference existing Wassette permission system (crates/policy/)
• Align with OCI artifact loading mechanism (crates/wassette/src/loader.rs)
• Consider compatibility with proposed headless deployment mode from issue Proposal: Headless Deployment Mode for Wassette #307

3. Deliverables

• Create docs/design/kubernetes-operator.md with CRD schema specifications
• Document CRD field mappings to existing Wassette concepts
• Include example YAML manifests showing typical usage
• Add validation rules and constraints for CRD fields
• Document relationship to MCP JSON-RPC API requirements

Acceptance Criteria

• CRD schemas are fully documented with field descriptions
• Example manifests demonstrate common use cases (loading OCI component, applying policies)
• Design addresses dynamic loading and routing requirements from parent issue
• Schema design is reviewed and validated against existing Wassette architecture
• Documentation includes migration path considerations for existing Wassette deployments

Testing Strategy

This is a design task, so testing is primarily design validation:

• Schema validation against Kubernetes CRD OpenAPI schema requirements
• Example manifest validation using kubectl --dry-run
• Peer review of design document for completeness and feasibility

Dependencies

None - this is the foundational subtask that other implementation tasks will depend on.

References

• Existing Wassette architecture: docs/design/architecture.md
• Permission system: docs/design/permission-system.md
• Related issue on headless deployment: Proposal: Headless Deployment Mode for Wassette #307
• Kubernetes CRD documentation: (redacted)
  Related to Kubernetes Operator for mcp-wasmtime #20

AI generated by Plan for #20

[asw101]

Closing [subtask]s of parent issues.