Skip to content
← All starter build updates

Scheduling starter

Orbit

An appointment planner for choosing a service and organizing a personal schedule.

Live on VuraUpdated

Changed booking drafts invalidate old holds and ignore late replies; service selection proceeds into booking and cancellation history survives reload. Keyboard/date controls and local calendar downloads work.

Public sourceBUILD.mdOpen verified demo ↗In-app build guide
Orbit: actual released desktop product view after the shared typography refinement.
Preview captured · Explore the product ↗

Build phase

  1. PlannedComplete
  2. BuildingComplete
  3. Local checks passedComplete
  4. In reviewComplete
  5. Live on VuraCurrent phase

This tracks the recorded release phase. The checks below include later findings and ongoing refinements.

Product scope and intended patterns

The following describes the intended reference. Features are not a verification claim; recorded check results below define what has actually been tested.

Client-rendered workspace with explicit static route entries and a real bounded serverless API; demo data boundaries documented.

Learning journal

How to read this starter

Orbit is a hybrid scheduling reference with local reservations, serverless availability validation and safe ICS download.

Source map

Booking state

src/state/booking.js

Signals model service, date, slot, guest, availability result, status copy and reservations.

Availability API

src/api/availability.js

The function strictly validates services, slots, local reservations and overlap conflicts.

Shared calendar logic

src/data/studio.js

Services, deterministic slots, overlap math, display helpers and ICS text live in pure shared code.

Reservations page

src/pages/Reservations.jsx

The ICS control creates a temporary Blob URL, clicks it and revokes it after download.

API tests

test/orbit.test.js

Tests cover open slots, demo holds, local conflicts, strict service validation, ICS text, overlap boundaries and bounded JSON.

Responsive application stylesheet

src/styles.css

Bounded headings and full-height brand and form controls retain the booking workflow.

Code patterns worth copying

Validate local reservations strictly at the API boundary

src/api/availability.js

Display fallbacks are fine in the UI. Posted reservation data needs strict lookup before it participates in conflict math.

const activeLocal = [];

Download ICS through a temporary Blob URL

src/pages/Reservations.jsx

The button creates the URL at click time instead of rendering an unsafe data: href into the document.

function downloadIcs(reservation) {
  const url = URL.createObjectURL(new Blob([createIcs(reservation)], { type: 'text/calendar;charset=utf-8' }));
  const anchor = document.createElement('a');
  anchor.href = url;
  anchor.download = `${reservation.id}.ics`;
  anchor.click();
  setTimeout(() => URL.revokeObjectURL(url), 1000);
}

Permit booking only from the verified draft

src/state/booking.js

The key includes service, date, start and local reservations. A successful response for a prior selection is not permission to book the current one.

export const canBook = computed(() => !pending() && availability()?.ok === true && verifiedDraft() === draftKey());

Use the shared stylesheet on application routes

src/styles.css

Bounded headings and full-height brand and form controls retain the booking workflow.

.brand {
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  color: var(--coral);
  text-decoration: none;
  text-transform: none;
  font-size: 24px;
  line-height: 1.4;
  font-weight: 700;
  letter-spacing: -.02em;
}

Real issues and fixes

Mobile booking heads need a measured clamp

Problem
The Orbit brand scale worked on desktop, but the booking page head could dominate the first mobile viewport before the controls appeared.
Fix
Add a page-head h1 clamp and a narrower mobile max-width so the service/date/slot controls stay in view.
Proof
The responsive CSS now has route-specific page-head sizing and mobile smoke covers booking flow from the generated app.
Takeaway
A dramatic display face still needs route-level clamps when the workflow starts below the headline.

Display fallback caused a phantom reservation conflict

Problem
The API initially reused a display helper that falls back to the first service when an id is unknown.
Fix
Use findServiceStrict in the serverless API and keep the forgiving helper for display-only code.
Proof
The API test rejects unknown local reservation service ids and still detects valid local conflicts after strict validation.
Takeaway
A UI fallback can become a security or correctness bug when copied into a server boundary.

Before

const reservationService = findService(reservation.serviceId);
activeLocal.push({ start: reservation.start, duration: reservationService.duration });

After

const reservationService = findServiceStrict(reservation.serviceId);
if (!reservationService) {
  errors.push('Local reservations must reference known Orbit services.');
  continue;
}

Calendar export needed a safe download path

Problem
An early data:text/calendar href was unsafe to render as an anchor URL.
Fix
The reservations page now creates a Blob URL on click and revokes it after the download starts.
Proof
The browser smoke exercises the ICS button from the reservations ledger, and unit tests verify VCALENDAR text generation.
Takeaway
Generate download URLs at the interaction boundary rather than storing unsafe URLs in render state.

Availability is not permission for a different draft

Problem
Changing service, slot or local reservations after a check could reuse a success for the wrong selection.
Fix
Fingerprint the draft, invalidate verified state on changes, block concurrent checks, discard responses for changed drafts and verify the returned service/start before enabling booking.
Proof
Delayed fetch regressions change the selection during a check and require a fresh check; normal booking, local conflict and ICS export tests remain.
Takeaway
A validated response authorizes its submitted draft, not whichever controls happen to be visible later.

What went smoothly

  • Services and slot fixtures are deterministic October 2026 data, which keeps screenshots and API tests stable.
  • Overlap math is pure shared code, so the API and unit tests can exercise booking logic without a browser.
  • Pure overlap helpers and strict service lookup remained the API boundary; the browser added draft ownership without pretending to create cross-user locks.
  • Shared local typography, subtle panels and 44px native controls unify service, booking, receipt and build routes without changing draft verification.

Boundaries to preserve

  • Reservations are private to the current browser unless a durable calendar backend is added.
  • The availability function validates local and demo holds, but it does not create shared locks across users.

Verification record

Build journal

  1. · Live on Vura

    Shared typography release captured from production

    Published shared typography and responsive control refinements are tied to the exact live deployment and source revision. Actual released captures replace the previous gallery preview; existing product behavior and source-grounded lessons are retained.

  2. · Live on Vura

    Product-depth iteration released and exercised

    Changed booking drafts invalidate old holds and ignore late replies; service selection proceeds into booking and cancellation history survives reload. Keyboard/date controls and local calendar downloads work.

  3. · Live on Vura

    Reviewed source ready for release verification

    Unique product identities and deeper workflows are implemented and independently reviewed. Existing releases remain accessible while new source is published and fresh deployments are exercised.

  4. · Live on Vura

    Product-depth iteration in progress

    Invalidating obsolete booking holds after draft changes and making service selection and cancellation history consistent. The current source and deployment links still identify the previous verified release.

  5. · Live on Vura

    Live corrections verified after independent follow-up

    The booking page uses a compact route heading and visible Service/Date/Time groups inside the first viewport. Slots, local reservations and ICS remain explicitly local-demo workflows.

  6. · Live on Vura

    Design refinement released for live workflow review

    Booking fields have visible group labels and a proper page hierarchy. Service, date and time selection passed live checks; local reservations remain explicitly local.

  7. · Live on Vura

    Independent live design review started

    The existing public app remains available while a new design review examines hierarchy, typography, navigation and workflow clarity. Actual findings and before/after repairs will be recorded as they are verified.

  8. · Live on Vura

    Hosted reference rechecked after documentation review

    Public source, green CI and the live app were checked together after the clean-machine documentation pass. Lessons and limitations now reflect the implemented code rather than pending pre-release work.

  9. · Live on Vura

    Final source and CI checkpoint verified

    The public source and build reference match the released learning journal, and the source workflow is green. The demo remains live at the same verified deployment; README and CI-only refinements did not change application code.

  10. · Live on Vura

    Clean-machine browser setup documented

    The README now installs the locked Chromium engine after npm ci and explains the Linux system-library prerequisite. The hosted application is unchanged; code examples, repair notes and boundaries remain source-backed.

  11. · Live on Vura

    Public template and Vura release

    The reviewed implementation is available from its independent repository and real hosted URL. Detailed code examples and actual repair notes are linked below.

  12. · In review

    Design review cleared; release verification underway

    The local implementation is complete and revised visual evidence has passed review. Source and demo links will appear only after publication and hosted verification.

  13. · In review

    Local build ready for specialist review

    The implementation owner completed the local build and workflow checks. No public source release or hosted verification is claimed yet.

  14. · Planned

    Product scope recorded

    This is a planned starter, not a working release. Implementation, tests, public source and deployment evidence will be added as they are completed.

Implementation lessons

Known limitations

Remaining work and blockers

No release blockers are recorded for this snapshot.

Using this as an agent reference

Read the public README and BUILD.md, reproduce the recorded checks and inspect the source before adapting the starter. A live demo, where available, provides separate deployed evidence.

Agent workflowSignalsEffectsGlobal stateRouting