Feature: Add a `kongctl create -f` command which creates (best effort) input resources

[rspurgeon]

Following the same pattern as:

• kongctl apply -f <inputs> # create or update
• kongctl sync -f <inputs> # create update or delete
• kongctl delete -f <inputs> # delete

Add a command to create resources without first checking state.

kongctl create -f <inputs>

This will perform a best effort attempt to create all the input resources with the following caveats:

• It will not first check existing state
• It will not update existing resources
• If a create (POST) fails, it will warn and continue with the input resource set
• It will create children of parents even if they already exist and the create fails for the parent

[github-actions]

🎯 Agentic Issue Triage

Summary: This is a well-scoped feature request to add a kongctl create -f (file) command that performs a best-effort, fire-and-forget bulk POST of all input resources — skipping pre-flight state checks, not updating existing resources, and continuing on individual failures. It completes the declarative command family alongside apply, sync, and delete.

📐 Architecture Analysis

The existing declarative commands (apply, sync, delete) all share a common pipeline in internal/cmd/root/products/konnect/declarative/declarative.go:

1. Verb thin-wrapper in internal/cmd/root/verbs/(verb)/ delegates to konnect.NewKonnectCmd(Verb) or declarative.NewDeclarativeCmd(Verb)
2. Planner generates a *planner.Plan with a mode (PlanModeApply, PlanModeSync, PlanModeDelete)
3. Executor runs the plan via executor.NewWithOptions(..., executor.Options{Mode: ...})

For create, a new PlanModeCreate would be needed. The key behavioural differences from apply (PlanModeApply):

Concern	apply	create (proposed)
Pre-flight state check	Yes (GET before POST)	No
Update existing	Yes (PUT/PATCH)	No
On POST failure	Abort or error	Warn + continue
Children of failed parent	Skip	Still attempt

This suggests PlanModeCreate would short-circuit the state-fetching phase in the planner and only emit ActionCreate operations, while the executor's error-handling path for this mode would warn-and-continue rather than abort.

✅ Implementation Checklist

• Add PlanModeCreate constant to internal/declarative/planner/
• Implement planner logic for PlanModeCreate:
  • Skip fetching remote state (no GET before each resource)
  • Emit only ActionCreate (POST) operations for all input resources
  • Preserve parent→child ordering from the resource graph
• Add executor handling for PlanModeCreate:
  • On POST failure: log warning, mark resource as failed, continue (do not abort)
  • Children of a failed parent should still be attempted
• Add newDeclarativeCreateCmd() in declarative.go and wire runCreate() using the shared planner→executor pipeline
• Add verb thin-wrapper internal/cmd/root/verbs/create/create.go (follow pattern of apply.go)
• Register create verb in the root command
• Add --auto-approve and --dry-run flag support (consistent with other commands)
• Add unit tests for new planner mode
• Add integration/e2e test scenario for kongctl create -f
• Update docs/ with usage examples for the new command

🔍 Key Files to Reference

• internal/cmd/root/products/konnect/declarative/declarative.go — main implementation; add newDeclarativeCreateCmd() and runCreate() here
• internal/cmd/root/verbs/apply/apply.go — template for the verb thin-wrapper
• internal/declarative/planner/ — add PlanModeCreate here
• internal/declarative/executor/ — add warn-and-continue error handling for the new mode
• planning/DECLARATIVE_RESOURCE_IMPLEMENTATION_GUIDE.md — primary guide for declarative resource implementation work

💡 Design Nudges

• Idempotency note: Since this skips state checks, running create -f twice on the same file will generate 409 Conflict errors on the second run. Consider surfacing a clear user-facing message for 409s specifically (e.g. "resource already exists, skipping") to avoid confusion.
• Output format: The execution result reporter should clearly distinguish "created", "skipped (already exists)", and "failed" to give users actionable feedback.
• Flag consistency: Consider whether --plan input (pre-generated plan files) should also be supported for create, as it is for apply and sync.
• Relation to apply: It may be worth documenting when to use create vs apply — create trades speed (no GET) for idempotency. This is valuable in bootstrapping/seeding scenarios where resources are guaranteed new.

Generated by Opened Issue Triage for issue #572 · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/issue-triage.md@69b5e3ae5fa7f35fa555b0a22aee14c36ab57ebb