# noCV engineering task library Content version 5 Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs. Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence. ## CAL — A booking connector that respects calendar reality A fictional consultancy books appointments across time zones. The first connector duplicates events after timeouts and offers slots during stale calendar sync. Use a local calendar-provider double and synthetic calendars. **Field:** Integrations. **Suggested stack:** TypeScript, PostgreSQL, HTTP, IANA time zones. **Engineer value:** Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. **Company value:** Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. **Delivery agreement:** A local booking connector with deterministic provider scenarios and an operations guide. ### Setup prerequisites - Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. - Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. ### Represent time and availability Offer only valid, explainable slots from fresh calendar data. #### CAL-101 — Reject local times that do not identify one instant **Task · High priority · Intermediate** noCV practice brief v5 · CAL-101 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Represent time and availability. Depends on: No preceding ticket. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Backend 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A booking form submits 01:30 on a daylight-saving fallback day without an offset. Store an instant plus display zone and explicitly handle ambiguous or nonexistent local times. Acceptance criteria - Bookings store UTC start/end instants and an IANA display-zone identifier. - Nonexistent local times are rejected with a selectable valid alternative. - Ambiguous local times require an explicit offset or occurrence choice and preserve that choice. Implementation constraints - Use established time-zone APIs or libraries; do not hard-code seasonal offsets. Verification - Test a normal date and both sides of a known spring gap and autumn overlap in a fixture zone. - Submit an unknown zone and an end before start and verify validation errors without provider calls. Deliverables - Booking time contract and daylight-saving boundary cases Rollout and recovery: Validate time inputs before availability or event creation; keep existing stored instants unchanged during migration. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CAL-102 — Merge overlapping busy intervals before offering slots **Task · Medium priority · Foundational** noCV practice brief v5 · CAL-102 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Represent time and availability. Depends on: CAL-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Integrations 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Two overlapping provider events produce a false free gap between them. Normalize busy intervals and apply the agreed booking duration and buffer. Acceptance criteria - Overlapping and adjacent intervals merge according to documented half-open boundaries. - Offered slots fit completely within working hours after pre/post buffers are applied. - Zero-length or reversed provider intervals are rejected as malformed input. Implementation constraints - Keep interval calculations in UTC; convert working-hour boundaries from the declared zone. Verification - Merge 09:00-10:00 and 09:30-10:30 and confirm no slot appears at 10:00. - Test a slot ending exactly at closing time with and without a post-booking buffer. Deliverables - Interval normalizer and slot boundary examples Rollout and recovery: Compare new slot output with fixture expectations in preview mode before exposing booking actions. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CAL-103 — Label unavailable or stale free/busy data instead of showing open slots **Bug · High priority · Intermediate** noCV practice brief v5 · CAL-103 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Represent time and availability. Depends on: CAL-102. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 80% · API design 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A free/busy request times out and the connector treats an empty response as an empty calendar. Distinguish confirmed free time from unknown availability. Acceptance criteria - Availability responses include fetched-at time, freshness state, and provider outcome. - A timeout, malformed response, or expired cache produces unknown availability and no bookable slots. - Fresh empty busy data can produce slots and remains distinguishable from failure. Implementation constraints - Use a configurable freshness limit and injected clock. Verification - Return fresh empty data and verify valid working-hour slots. - Return timeout and separately age cached data beyond the limit; neither may expose bookable slots. Deliverables - Availability state model and stale-data tests Rollout and recovery: Enable fail-closed availability before adding booking creation; users receive a retry state while provider data is unknown. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Create and change bookings safely Handle concurrency, retries, and external side effects explicitly. #### CAL-104 — Reserve a slot atomically when two customers choose it **Story · High priority · Expert** noCV practice brief v5 · CAL-104 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Create and change bookings safely. Depends on: CAL-103. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Integrations 30% · Distributed systems 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Two clients load the same available slot and submit together. Add an internal reservation transaction and a final provider availability check before creating an event. Acceptance criteria - Overlapping active reservations for one resource are prevented by a database-backed invariant. - Only the winning reservation can enqueue event creation through a transactional outbox. - The product distinguishes internal reservation guarantees from provider-side races when the provider lacks atomic hold support. Implementation constraints - Use a barrier-controlled race with two synthetic customers. - If the provider cannot guarantee exclusive booking, record the residual conflict state and provide reconciliation. Verification - Submit two overlapping reservations concurrently and assert one winner and one outbox event. - Introduce an external busy event after the first check and verify the booking is rejected or explicitly reconciled under the declared provider contract. Deliverables - Reservation constraint, outbox flow, and provider-race analysis Rollout and recovery: Activate one resource at a time with explicit provider guarantees; pause creation if unresolved conflicts accumulate. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CAL-105 — Reconcile a create-event timeout before trying again **Bug · High priority · Advanced** noCV practice brief v5 · CAL-105 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Create and change bookings safely. Depends on: CAL-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Distributed systems 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The calendar provider creates the appointment but drops its response. Retrying with a new request identifier currently creates a second event. Preserve creation identity and reconcile uncertainty. Acceptance criteria - Each booking has a stable provider request identity persisted before the first call. - A lost response triggers lookup by that identity or an explicit uncertain state when lookup is unsupported. - A matching existing event is linked once; conflicting details block automatic completion. Implementation constraints - Use the local double to model accepted-then-timeout. - Do not claim exactly-once provider behavior without the required idempotency contract. Verification - Lose the first create response and assert one provider event after reconciliation. - Return an event with the same identity but different times and confirm the booking enters conflict without another create. Deliverables - Idempotent creation adapter and uncertain-outcome tests Rollout and recovery: Require reconciliation support before enabling retries; unsupported providers remain in manual resolution on ambiguous outcomes. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CAL-106 — Move a booking only if its current revision still matches **Story · High priority · Advanced** noCV practice brief v5 · CAL-106 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Create and change bookings safely. Depends on: CAL-105. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Backend 30% · Distributed systems 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. An agent reschedules a booking from an old browser tab after a colleague already moved it. Add revision-aware rescheduling and retain the original slot until the new operation is settled. Acceptance criteria - Reschedule requests include the expected booking revision and are rejected when stale. - The proposed new slot passes reservation and availability checks before the provider update. - Provider failure or uncertainty leaves a documented pending/conflict state and does not silently mark both slots free. Implementation constraints - Use provider conditional updates when the adapter supports them. - Record before and proposed intervals in an append-only operation record. Verification - Reschedule an unchanged booking and verify one final interval and incremented revision. - Race two reschedules and simulate a provider timeout; verify explicit conflicts and no duplicate successful move. Deliverables - Rescheduling state transitions and race/failure cases Rollout and recovery: Enable rescheduling after create reconciliation is stable; fall back to operator resolution for uncertain provider updates. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Recover provider and account changes Manage updates, cancellation, expiry, and reconnect without duplicates. #### CAL-107 — Make repeated cancellation safe and tenant scoped **Story · High priority · Intermediate** noCV practice brief v5 · CAL-107 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover provider and account changes. Depends on: CAL-105. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Security 30% · Backend 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A client double-clicks Cancel while a support agent cancels from another screen. The connector must converge on one cancellation without allowing another tenant to cancel by event ID. Acceptance criteria - Cancellation resolves the booking through tenant and actor authorization before accessing provider IDs. - Repeated authorized cancellation converges on the same terminal result. - Provider not-found is accepted only after verifying the expected booking/provider mapping, and other provider errors remain visible. Implementation constraints - Keep provider event IDs out of caller-controlled authority decisions. Verification - Send concurrent cancellation requests and assert one logical cancellation history. - Attempt cancellation from another tenant and verify no provider request is made. Deliverables - Scoped cancellation service and idempotency/access tests Rollout and recovery: Expose cancellation with retry-safe state transitions; retain pending cancellation during provider outages rather than claiming success. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CAL-108 — Refresh expired connector credentials once per account **Bug · High priority · Expert** noCV practice brief v5 · CAL-108 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover provider and account changes. Depends on: CAL-105. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Security 30% · Distributed systems 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Ten jobs receive token-expired at once, all refresh, and a rotated token is overwritten by an older response. Serialize refresh by connector identity and persist credential revisions safely. Acceptance criteria - Concurrent expiry responses share one refresh operation per connector account. - Credential writes use version checks so an older refresh cannot overwrite a newer rotation. - A revoked grant stops new provider mutations, records reconnect-required, and never logs credential values. Implementation constraints - Use synthetic opaque tokens and a local token endpoint double. - Store credentials through a secret-store interface; do not hard-code a production key. Verification - Expire a token under ten concurrent calls and assert one refresh with successful versioned reuse. - Return refresh responses out of order and a revoked grant; verify no stale overwrite and no further mutations. Deliverables - Credential lifecycle port and refresh-race tests Rollout and recovery: Canary the new refresh path on a synthetic connector; force reconnect when credential authority is ambiguous. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CAL-109 — Ignore duplicate calendar notifications and detect missed updates **Story · High priority · Advanced** noCV practice brief v5 · CAL-109 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover provider and account changes. Depends on: CAL-106, CAL-107, CAL-108. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Distributed systems 30% · Security 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Provider notifications arrive twice, then a subscription expires and updates stop. Treat notifications as sync hints and maintain a separate reconciliation cursor and subscription deadline. Acceptance criteria - Authenticated duplicate notifications schedule at most one active sync for the connector. - Sync advances its provider cursor only with committed local changes. - Expired subscriptions or invalid cursors trigger an explicit refresh/reconnect path and mark availability stale. Implementation constraints - Validate the local notification authentication contract before trusting connector metadata. - Do not use notification arrival order as event revision order. Verification - Send duplicate and invalid-auth notifications and count scheduled jobs. - Expire a subscription and invalidate a cursor; confirm availability becomes unbookable until a successful resync. Deliverables - Notification ingestion, sync checkpointing, and expiry scenarios Rollout and recovery: Enable notification ingestion alongside periodic reconciliation; pause booking when either path cannot establish fresh availability. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CAL-110 — Show operators which bookings need recovery after reconnect **Task · Medium priority · Foundational** noCV practice brief v5 · CAL-110 · A booking connector that respects calendar reality Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover provider and account changes. Depends on: CAL-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Backend 30% · Security 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. After reconnecting an account, operations cannot tell which bookings were created, moved, or cancelled during the outage. Build a scoped recovery list with safe identifiers and next actions. Acceptance criteria - The list separates pending creation, uncertain update, pending cancellation, and resolved operations. - Each row includes safe booking reference, last attempt time, failure category, and permitted recovery action. - Reading the list never sends invitations, creates events, or retries an operation implicitly. Implementation constraints - Omit attendee contact details from generic diagnostics. - Actions invoke the existing authorized lifecycle methods. Verification - Populate one operation in each state and verify labels and action availability. - Open the list as an unauthorized tenant and confirm denial with zero provider activity. Deliverables - Recovery list projection and reconnect operator guide Rollout and recovery: Release read-only recovery visibility first; activate explicit retry actions only through the already verified state transitions. Project prerequisites: Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens. Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required. Engineer value: Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries. Company value: Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence.