HYPERFLEET-1295 - feat: Conditional resource creation

[mliptak0]

Summary

Documents the new lifecycle.create.when adapter DSL feature (conditional per-resource creation) added in [hyperfleet-adapter#HYPERFLEET-1295](https://issues.redhat.com/browse/HYPERFLEET-1295), and reorganizes the per-resource lifecycle docs under a shared lifecycle/ directory so the create and delete designs sit side by side as a matched pair.

HYPERFLEET-1295

Changes

• Added adapter-lifecycle-create-design.md describing lifecycle.create.when: DSL shape, required fields, skip/ignore/fail-closed semantics, and how it composes with pre-discovery and adapter.resourcesSkipped
• Moved adapter-deletion-flow-design.md → lifecycle/adapter-lifecycle-delete-design.md, establishing lifecycle/ as the home for per-resource lifecycle.<operation>.when designs, and updated all relative links inside the moved file for its new depth
• Updated every cross-reference to the deletion design doc across the architecture repo (ADR 0012, adapter-frame-design.md, adapter-flow-diagrams.md, condition-mapping-design.md, hard-delete-design.md, force-deletion-design.md) to point at the new path
• Added an "Update (HYPERFLEET-1295)" note to the deletion design's rejected-alternatives section clarifying that lifecycle.create.when reuses the same purpose-built lifecycle.<operation>.when shape rather than reintroducing the generic when + action dispatcher that was rejected for deletion
• Linked both lifecycle docs from adapter-frame-design.md's document index

Notes

Verified all relative markdown links resolve correctly after the file move (both within the moved/renamed file and in every external referencer) — no dangling references to the old adapter-deletion-flow-design.md path remain anywhere in the repo.

The create-design doc's semantics were checked line-by-line against the corresponding hyperfleet-adapter implementation (internal/executor/resource_executor.go, internal/configloader/validator.go): skip-vs-ignore behavior, fail-closed CEL error handling, discovery requirement, and the INFO-level skip log all match the shipped code.

Test Plan

• Verified all relative links in touched/moved docs resolve to existing files
• Verified no remaining references to the old adapter-deletion-flow-design.md path
• Cross-checked new doc's technical claims against the hyperfleet-adapter implementation
• Doc reviewed by a teammate for clarity/accuracy

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign sherine-k for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

Warning

Review limit reached

@mliptak0, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 44 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 15f9de7e-8cbc-44a6-862a-53404eddf14a

📥 Commits

Reviewing files that changed from the base of the PR and between cbcb10a and fe90934.

📒 Files selected for processing (8)

• hyperfleet/adrs/0012-hard-delete-mechanism-after-adapter-reconciliation.md
• hyperfleet/components/adapter/framework/adapter-flow-diagrams.md
• hyperfleet/components/adapter/framework/adapter-frame-design.md
• hyperfleet/components/adapter/framework/lifecycle/adapter-lifecycle-create-design.md
• hyperfleet/components/adapter/framework/lifecycle/adapter-lifecycle-delete-design.md
• hyperfleet/components/api-service/condition-mapping-design.md
• hyperfleet/components/api-service/hard-delete-design.md
• hyperfleet/docs/force-deletion-design.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

✨ Simplify code

• Create PR with simplified code

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[rafabene]

nit (Improvement) — Confidence: High

The description "Per-resource conditional deletion" mischaracterizes this document's scope. The deletion flow design doc covers the entire deletion workflow — soft deletion, pending deletion, hard-delete signal, adapter cleanup, status reporting, edge cases, observability, subresource deletion, and more. The lifecycle.delete.when conditional gate is just one section.

A reader scanning this index for "how does adapter deletion work?" might skip the entry thinking it only covers the conditional gate. The creation doc description is accurate (it IS specifically about the conditional gate), which makes the asymmetry misleading.

Suggested change

	- [Adapter Lifecycle: Deletion](./lifecycle/adapter-lifecycle-delete-design.md) - Per-resource conditional deletion
	- [Adapter Lifecycle: Deletion](./lifecycle/adapter-lifecycle-delete-design.md) - Deletion workflow, cleanup, status reporting, and conditional deletion