Derive a collision-resistant preview identity
Two repositories both open pull request 42 and receive the same environment name, causing one preview to replace the other.
- Focused work estimate
- 1h 30m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Resource identity · Input validation
Estimated field mix
- DevOps70%
- Cloud infrastructure30%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional product team creates local preview environments for pull requests. Names collide, fixtures copy more data than needed, failed provisioning leaks resources, and merged changes leave previews running. Build an infrastructure simulator with fake DNS, storage, and deployment providers; no cloud account or live domain is supplied.
Setup prerequisites
- Resource graphs
- Idempotency
- Tenant isolation
Preceding work
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Identity binds repository, immutable revision, and pull-request identity
- Human-readable alias maps to one immutable environment ID
- Length and character limits are enforced before provider calls
Implementation constraints
- Do not use branch text as the sole authority or resource identity.
Verification to include
- Create previews for same-number requests in two repositories.
- Use oversized and normalization-colliding names and confirm no resource mutation.
Deliverables
- Preview identity contract and collision tests
Rollout and recovery
Adopt IDs in state first while retaining old aliases for display.
Value of the work
For the engineer: Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation.
For the team: Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.