# 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. ## TRIP — A commuter planner that explains uncertainty The fictional Northline commuter app plans bus and rail trips from synthetic timetable and alert feeds. Riders save journeys and choose optional reminders. The scope excludes ticket purchases, safety guarantees, and continuous location collection. **Field:** Mobile. **Suggested stack:** Kotlin, Jetpack Compose, Room, JUnit, Android emulator. **Engineer value:** Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. **Company value:** Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. **Delivery agreement:** Work from fixed fixtures and an emulator. Deliver individual issues or three-to-four focused phase increments. ### Setup prerequisites - Synthetic timetable with explicit time zones and service dates - Departure, alert, and permission adapters with failure fixtures ### Make journeys readable Present stable saved trips and correct service times. #### TRIP-101 — Give saved journeys names that survive station renames **Story · Low priority · Foundational** noCV practice brief v5 · TRIP-101 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make journeys readable. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 80% · Database engineering 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. Central Station becomes Central Exchange in a feed update and a saved commute disappears. Save journeys by station identity and let riders keep a personal label. Acceptance criteria - Saved journeys use stable station IDs and optional rider labels. - Renaming a station updates its display without duplicating the journey. - A removed station shows an unavailable state with an edit action instead of silently deleting the journey. Implementation constraints - Limit labels and render them as text; no account sync is required. Verification - Save Home to Office and apply a station-name update; identity and label remain. - Remove a referenced station and reload; the saved journey remains editable with an unavailable endpoint. Deliverables - Saved-journey model and station-update fixture tests Rollout and recovery: Migrate a copied local fixture database first; retain original IDs if label migration fails. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. #### TRIP-102 — Keep the last train on the correct service day **Bug · High priority · Advanced** noCV practice brief v5 · TRIP-102 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make journeys readable. Depends on: No preceding ticket. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 80% · 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. A Saturday service departing after midnight appears under Sunday and disappears from the late-night search. The feed expresses service-day times beyond 24:00. Acceptance criteria - Service date and elapsed service-day time map to an instant using the feed time zone. - Display uses rider-friendly local date/time while retaining the original service identity. - Unsupported or ambiguous feed times produce an explicit data error rather than a guessed departure. Implementation constraints - Write the conversion policy for daylight-saving transitions; do not parse service times as ordinary clock-only strings. Verification - Resolve a Saturday 25:10 service to the expected next-calendar-day instant and keep Saturday service identity. - Exercise the agreed clock-change fixtures and malformed time input; no negative journey duration or silent guess appears. Deliverables - Service-time conversion module and boundary fixture table Rollout and recovery: Compare converted times against curated synthetic examples; hide affected feed entries if conversion fails. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. #### TRIP-103 — Explain transfers without relying on line colors **Task · Medium priority · Foundational** noCV practice brief v5 · TRIP-103 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make journeys readable. Depends on: TRIP-102. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Accessibility 60% · Mobile 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 journey card distinguishes Line 4 from Line 8 only by color. Riders using grayscale or a screen reader cannot tell where to change. Acceptance criteria - Each leg shows mode, line label, destination, and boarding/alighting stops in reading order. - Transfers state walking and waiting time in text. - Large text and grayscale preserve every required leg distinction. Implementation constraints - Keep decorative map graphics out of the essential accessible description. Verification - Read a two-transfer fixture with assistive navigation and compare spoken order to itinerary order. - Use grayscale and large text; a canceled leg must remain identifiable without its color or icon. Deliverables - Accessible journey-leg card and device walkthrough Rollout and recovery: Release text semantics with the existing card layout first; revert visual changes independently if leg details become clipped. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. ### Handle changing feeds Keep live data, cancellations, and stale results coherent. #### TRIP-104 — Label stale departures when the live feed stops responding **Story · High priority · Intermediate** noCV practice brief v5 · TRIP-104 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle changing feeds. Depends on: TRIP-102. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 60% · Real-time 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 departures screen keeps displaying an old prediction after a feed outage. A rider mistakes a 12-minute-old estimate for a live arrival. Acceptance criteria - Predictions show source update time and become stale at the configured fixture threshold. - Scheduled times remain available but are visibly distinguished from current predictions. - A failed refresh preserves readable departures and provides a retry action. Implementation constraints - Calculate staleness from trusted feed timestamps with a documented clock-skew allowance. Verification - Advance a fake clock across the freshness threshold and inspect the label change. - Return a future-dated update beyond allowed skew and then fail refresh; do not display it as trustworthy live data. Deliverables - Departure freshness policy and fake-clock tests Rollout and recovery: Enable stale labels for one synthetic feed; disable live prediction display if timestamps cannot be validated. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. #### TRIP-105 — Apply cancellation updates to the right departure instance **Bug · High priority · Advanced** noCV practice brief v5 · TRIP-105 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle changing feeds. Depends on: TRIP-104. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 50% · Real-time systems 30% · Data engineering 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. Canceling the 08:10 Line 4 also marks tomorrow’s 08:10 as canceled because the cache key contains only the route. Reconcile alerts by departure identity. Acceptance criteria - Cancellation identity includes service date and trip instance rather than route label alone. - A newer correction can restore a departure while an older cancellation cannot overwrite it. - Unknown alert references remain diagnosable without canceling unrelated trips. Implementation constraints - Define ordering from feed revision metadata, not arrival order on the device. Verification - Cancel today’s instance and verify tomorrow’s matching route stays available. - Deliver correction and cancellation out of order; the newest revision wins and unknown IDs change no journey. Deliverables - Departure alert reducer and ordering regression tests Rollout and recovery: Shadow-reconcile synthetic alerts before display; fall back to a general service notice if precise mapping is unavailable. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. ### Respect device conditions Handle lifecycle, reminders, and permissions deliberately. #### TRIP-106 — Stop refreshing a journey after the rider leaves it **Bug · Medium priority · Intermediate** noCV practice brief v5 · TRIP-106 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Respect device conditions. Depends on: TRIP-104. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Opening several saved journeys starts several permanent refresh loops. The app continues polling all of them in the background and occasionally displays the wrong result. Acceptance criteria - Only the visible journey owns an active foreground refresh loop. - Backgrounding pauses polling and foreground return performs one bounded freshness check. - Late results from a departed journey cannot update the active journey. Implementation constraints - Use lifecycle-aware cancellation plus request identity; do not request a background location service for refresh. Verification - Switch among three journeys and inspect that only one loop remains active. - Background during an in-flight request and return after expiry; exactly one fresh check occurs and stale results are ignored. Deliverables - Lifecycle-aware refresh coordinator and request-count tests Rollout and recovery: Pilot with a short foreground session trace; disable automatic refresh if loop ownership regresses and keep manual refresh. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. #### TRIP-107 — Make departure reminders honest about permission and schedule changes **Story · Medium priority · Advanced** noCV practice brief v5 · TRIP-107 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Respect device conditions. Depends on: TRIP-105, TRIP-106. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 100%. 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 rider enables a reminder after denying notifications, then assumes an alert will arrive. Rescheduled departures also leave the old reminder behind. Acceptance criteria - Reminder state distinguishes requested, scheduled, denied, canceled, and expired. - Changing the departure revision cancels the old schedule before confirming its replacement. - The app offers an in-app alternative when device notification capability is unavailable. Implementation constraints - Request permission only after an explicit reminder action and disclose the limits of delivery timing. Verification - Allow notifications, schedule a reminder, then change departure time; one current schedule remains. - Deny permission and cancel the trip during rescheduling; no successful reminder claim or orphan schedule remains. Deliverables - Reminder state coordinator and permission-change cases Rollout and recovery: Pilot opt-in reminders on emulators and test devices; disable new scheduling if duplicate reminders are observed. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. #### TRIP-108 — Recover a route search when the timetable changes mid-session **Bug · High priority · Expert** noCV practice brief v5 · TRIP-108 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Respect device conditions. Depends on: TRIP-101, TRIP-105, TRIP-106. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 60% · Database engineering 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 timetable refresh replaces station and trip data while a route calculation still reads the old version. The result combines a new platform with a removed connection. Acceptance criteria - A search reads one timetable snapshot/version for its entire calculation. - A result from an obsolete snapshot is explicitly revalidated or replaced before being labeled current. - Interrupted dataset replacement leaves either the old complete dataset or the new complete dataset available. Implementation constraints - Use synthetic small datasets and a local transaction; implementing a nationwide routing engine is excluded. Verification - Swap timetable versions during calculation and verify every returned leg belongs to one version. - Fail replacement halfway through and restart; searches use a complete version and unavailable connections are not invented. Deliverables - Versioned timetable handoff and interrupted-update tests Rollout and recovery: Stage updates beside the active dataset; switch the active pointer back if validation fails and retain prior-version diagnostics. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. ### Prepare a measured release Explain limitations and verify the complete journey. #### TRIP-109 — Offer nearby stops without making location mandatory **Story · Medium priority · Intermediate** noCV practice brief v5 · TRIP-109 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare a measured release. Depends on: TRIP-101, TRIP-103. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 60% · Mobile 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 first screen demands location before showing any journeys. A rider who declines cannot search by station even though the timetable supports it. Acceptance criteria - Station search and saved journeys work without location permission. - Nearby stops request location only after an explicit action and show how approximate results are used. - Denial, timeout, and unavailable location return to a usable manual search without repeated prompts. Implementation constraints - Use a one-shot coarse-location adapter and do not persist coordinates in generic analytics. Verification - Deny location on first use and complete a manual station search. - Return an approximate fix and then a timeout; nearby results disclose approximation and manual search remains accessible. Deliverables - Optional nearby-stop flow and permission-free journey check Rollout and recovery: Release manual search before nearby suggestions; disable the location adapter if denial recovery or privacy checks fail. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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. #### TRIP-110 — Rehearse a disrupted commute with fixed feed data **Chore · Medium priority · Advanced** noCV practice brief v5 · TRIP-110 · A commuter planner that explains uncertainty Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare a measured release. Depends on: TRIP-107, TRIP-108, TRIP-109. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Mobile 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. Most checks cover a clean daytime trip. Before the pilot, rehearse a saved late-night commute through feed outage, cancellation correction, and app restart. Acceptance criteria - A deterministic scenario records which timetable revision, departure identity, and freshness label appear at each step. - Restart preserves the saved journey without restoring an obsolete reminder. - The handoff states fixture coverage and unresolved live-feed assumptions explicitly. Implementation constraints - Use a controllable clock and adapters; do not depend on actual transit services or notification delivery. Verification - Run the rehearsal twice and compare the ordered visible states. - Inject an invalid feed timestamp and an interrupted dataset update; no current-live label or mixed-version trip appears. Deliverables - Disruption rehearsal script and pilot support checklist Rollout and recovery: Require the fixed-data rehearsal before app updates; pause pilot expansion on misleading freshness or reminder state. Project prerequisites: Synthetic timetable with explicit time zones and service dates Departure, alert, and permission adapters with failure fixtures Engineer value: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design. Company value: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data. 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.