# 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. ## BCALENDAR — Calendar availability synchronization A fictional booking service supports consultants in multiple time zones. Recurring events, revoked access, and delayed callbacks cause missed conflicts. **Field:** Integrations. **Suggested stack:** TypeScript, iCalendar, HTTP. **Engineer value:** Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. **Company value:** Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. **Delivery agreement:** Deliver local availability calculations and sync behavior; send no invitations or calendar writes externally. ### Setup prerequisites - Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. ### Define temporal semantics Model instants, zones, and recurrence. #### BCALENDAR-101 — Distinguish all-day events from timed calendar intervals **Task · Medium priority · Foundational** noCV practice brief v5 · BCALENDAR-101 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define temporal semantics. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 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. An all-day absence becomes a twenty-four-hour UTC interval and shifts across local dates. Acceptance criteria - Represent all-day dates separately from instants. - Declare exclusive end semantics. - Preserve the event's timezone context. Implementation constraints - Do not infer an event zone from the server timezone. Verification - Render a timed event and all-day absence correctly. - Reject missing timezone context for ambiguous local times. Deliverables - Temporal data contract. Rollout and recovery: Version the contract before importing calendar records. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-102 — Resolve daylight-saving gaps and repeated local times **Task · High priority · Advanced** noCV practice brief v5 · BCALENDAR-102 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define temporal semantics. Depends on: BCALENDAR-101. Difficulty: Advanced. Estimated focused work: 180 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. A recurring appointment lands in a nonexistent local hour during a timezone transition. Acceptance criteria - Define explicit gap and overlap policies. - Keep original local time and selected offset. - Return ambiguity when policy cannot resolve the occurrence. Implementation constraints - Use a maintained timezone database available locally. Verification - Exercise a spring gap and autumn repeated hour. - Reject a silently guessed offset. Deliverables - Timezone resolution tests. Rollout and recovery: Keep affected appointments unresolved until policy is applied. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-103 — Expand recurrence within a bounded availability window **Task · High priority · Advanced** noCV practice brief v5 · BCALENDAR-103 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define temporal semantics. Depends on: BCALENDAR-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Performance engineering 40% · 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. An unbounded recurrence rule exhausts the availability request. Acceptance criteria - Require finite query start and end. - Limit emitted occurrences and processing work. - Honor exclusions and changed single occurrences. Implementation constraints - Reject unsupported recurrence forms explicitly. Verification - Expand a weekly rule with an exception. - Bound an excessive recurrence and reject unsupported syntax. Deliverables - Bounded recurrence engine. Rollout and recovery: Start with declared supported rules; preserve unsupported events as unavailable context. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. ### Synchronize availability Handle event updates and provider failures. #### BCALENDAR-104 — Apply event revisions without reviving cancelled occurrences **Bug · High priority · Advanced** noCV practice brief v5 · BCALENDAR-104 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize availability. Depends on: BCALENDAR-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Integrations 50%. 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 old series update recreates a cancelled individual appointment. Acceptance criteria - Track series and occurrence revisions separately. - Preserve cancellation tombstones. - Ignore stale updates with an observable reason. Implementation constraints - Arrival order is not event version authority. Verification - Update one occurrence in a series. - Replay an older series update after cancellation. Deliverables - Revision-aware event importer. Rollout and recovery: Adopt on synthetic calendars first; reconcile before enabling booking decisions. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-105 — Use incremental sync tokens without losing full-resync coverage **Task · High priority · Intermediate** noCV practice brief v5 · BCALENDAR-105 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize availability. Depends on: BCALENDAR-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Site reliability 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 provider invalidates a sync token, and the app interprets it as an empty calendar. Acceptance criteria - Distinguish token invalidation from no changes. - Start a bounded full sync on invalidation. - Keep existing availability marked stale until replacement completes. Implementation constraints - Never clear events because a provider request failed. Verification - Apply a normal incremental page. - Invalidate the token and preserve stale records during recovery. Deliverables - Sync-token recovery. Rollout and recovery: Pause definitive availability claims while full sync is incomplete. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-106 — Project busy intervals without exposing event descriptions **Task · High priority · Intermediate** noCV practice brief v5 · BCALENDAR-106 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize availability. Depends on: BCALENDAR-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · API design 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. Availability responses leak private appointment titles to bookers. Acceptance criteria - Expose only necessary busy intervals. - Scope calendars by current access grants. - Exclude titles, attendees, and notes from public projections. Implementation constraints - Private provider fields remain outside scheduling responses. Verification - Compute availability from authorized events. - Seed sensitive markers and verify they never appear in outputs. Deliverables - Privacy-preserving availability projection. Rollout and recovery: Replace detailed projections before public availability is enabled. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-107 — Stop provider calls immediately after access revocation **Bug · High priority · Advanced** noCV practice brief v5 · BCALENDAR-107 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize availability. Depends on: BCALENDAR-105, BCALENDAR-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Privacy engineering 30% · Integrations 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. Revoked calendars remain cached and continue receiving background refreshes. Acceptance criteria - Invalidate active grants and queued refresh authority. - Suppress cached private availability after revocation. - Make reconnect an explicit new authorization flow. Implementation constraints - Do not retry authorization failures as transient errors. Verification - Refresh an authorized calendar. - Revoke access mid-queue and verify no further authorized reads occur. Deliverables - Revocation handling. Rollout and recovery: Fail closed on uncertain grants; retain only allowed operational metadata. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. ### Rehearse edge cases Verify privacy, cutover, and recovery. #### BCALENDAR-108 — Detect overlapping booking attempts against one availability revision **Task · High priority · Advanced** noCV practice brief v5 · BCALENDAR-108 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse edge cases. Depends on: BCALENDAR-106, BCALENDAR-107. Difficulty: Advanced. Estimated focused work: 210 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 bookers see the same open slot before either reservation is committed. Acceptance criteria - Bind booking checks to a declared availability revision. - Serialize or atomically reject overlapping local reservations. - Represent external confirmation as pending when unknown. Implementation constraints - Use a local provider double; create no real events. Verification - Race two bookings for one slot. - Change provider availability during booking and expose the conflict. Deliverables - Booking consistency checks. Rollout and recovery: Keep short local reservations; reconcile unknown external outcomes before releasing them. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-109 — Assess polling versus callbacks for calendar freshness **Task · High priority · Expert** noCV practice brief v5 · BCALENDAR-109 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse edge cases. Depends on: BCALENDAR-105, BCALENDAR-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Integrations 30% · Site reliability 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. The provider's callbacks are delayed, but frequent polling consumes the request budget. Acceptance criteria - Compare bounded polling and callback-assisted approaches. - Declare acceptable staleness and request-budget assumptions. - Rehearse dropped callbacks, duplicates, and provider outages. Implementation constraints - Local measurements do not establish a live provider's delivery guarantees. Verification - Recover a missed callback through polling. - Exhaust the budget and show stale availability explicitly. Deliverables - Freshness tradeoff assessment. Rollout and recovery: Adopt a conservative refresh policy with visible age and a manual recovery path. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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. #### BCALENDAR-110 — Write the calendar recovery checklist for invalid sync state **Chore · Low priority · Foundational** noCV practice brief v5 · BCALENDAR-110 · Calendar availability synchronization Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse edge cases. Depends on: BCALENDAR-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. Support needs to recover a calendar without deleting local reservations. Acceptance criteria - Identify the calendar, grant, and sync revision. - Show safe resync and status commands. - Preserve local reservations while replacing imported events. Implementation constraints - No direct lifecycle-state edits. Verification - Recover an invalid token using the guide. - Reject recovery for a revoked grant. Deliverables - Calendar support runbook. Rollout and recovery: Rehearse against synthetic calendars before enabling a support action. Project prerequisites: Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases. Engineer value: Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections. Company value: Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization. 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.