Allow explicit compose resource names

[sjmiller609]

Summary

• add optional service-level and ingress-level name fields to hypeman compose
• use explicit names when rendering instance and ingress resources, while keeping compose ownership tags keyed by the logical service name
• validate explicit names and reject duplicate rendered instance or ingress names
• document the naming override with an environment-interpolated example

Test plan

• go test ./...
• ./scripts/build
• ./scripts/lint

---

Note

Medium Risk
Medium risk because it changes how compose renders and reconciles resource names, which can trigger replacements or conflicts for existing deployments when names are overridden or renamed.

Overview
Compose specs can now override rendered resource names. Services and ingress rules accept an optional name field that, when set, is used for the created instance/ingress name instead of the default <compose>-<service> / <compose>-<service>-<index> pattern.

Validation and reconciliation were updated to enforce name format/length, reject duplicate rendered names, and to plan replace actions when a compose-owned instance/ingress appears to have been renamed (including ingress rename disambiguation/conflict handling). Documentation and tests were expanded to cover env-interpolated naming examples and the new planning behavior.

^{Reviewed by Cursor Bugbot for commit 07530d1. Bugbot is set up for automated code reviews on this repo. Configure here.}

[firetiger-agent]

Firetiger deploy monitoring skipped

This PR didn't match the auto-monitor filter configured on your GitHub connection:

Any PR that changes the kernel API. Monitor changes to API endpoints (packages/api/cmd/api/) and Temporal workflows (packages/api/lib/temporal) in the kernel repo

Reason: PR modifies hypeman compose naming functionality, not kernel API endpoints or Temporal workflows as specified in the filter.

To monitor this PR anyway, reply with @firetiger monitor this.

[sjmiller609]

Addressed the Bugbot rename concern in b5479cc: compose now treats a compose-owned resource with the same logical service/resource tag but a different rendered name as a replace action, so name changes require --replace instead of leaving the old resource orphaned. Added instance and ingress rename tests.

[sjmiller609]

Addressed the second Bugbot ingress concern in 07530d1. Ingress rename replacement now ignores owned ingresses whose names are still desired by another rule, replaces only when exactly one stale owned ingress remains for the service, and reports a conflict when multiple stale candidates make the mapping ambiguous. Added tests for the safe rename, adding a second ingress, and ambiguous stale candidates.

For the README naming question: instance and ingress names live under different Hypeman resource types, so the same string across those two types is not a resource lookup conflict. The code validates duplicate rendered names within the same resource type.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 07530d1. Configure here.}

[cursor]

Multiple desired ingresses can replace same stale ingress

Medium Severity

When a service goes from one ingress to two (with both names changing), planIngressAction is called independently for each desired ingress with the same unmodified owned list and desiredServiceIngressNames map. A single stale owned ingress whose name isn't in the desired set appears as exactly one rename candidate for every new desired ingress for that service, causing multiple "replace" actions targeting the same ingressID. This incorrectly requires --replace for what partially should be a plain "create" and causes the same owned ingress to be deleted twice during execution.

Additional Locations (1)

• lib/compose/reconcile.go#L61-L65

 

^{Reviewed by Cursor Bugbot for commit 07530d1. Configure here.}

[cursor]

Rename detection bypasses conflict check against non-owned resources

High Severity

The new rename detection in planInstanceAction and planIngressAction returns a "replace" action without first checking the all list for name conflicts with non-owned resources. If a user renames an instance/ingress to a name already held by a non-owned resource, applyReplace deletes the old resource and then fails on create (name taken), causing data loss — the old resource is gone and the new one can't be created. Before this PR, this scenario safely fell through to the all conflict check.

Additional Locations (1)

• lib/compose/reconcile.go#L447-L454

 

^{Reviewed by Cursor Bugbot for commit 07530d1. Configure here.}