Skip to content
← All starter build updates

Operations starter

Signal

A service status site for communicating incidents and explaining operational health.

Live on VuraUpdated

Both incident detail routes render, request loaders use real timestamps and the stylesheet is served correctly. Cached overview and private uncached snapshot behavior passed live proof.

Public sourceBUILD.mdOpen verified demo ↗In-app build guide
Signal: 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.

Request-time SSR, a cached overview, static reference pages and a real serverless health API; simulated service data.

Learning journal

How to read this starter

Signal is a Vura server-rendered status page showing cached output, page config and a small serverless health route.

Source map

Cached server page

src/pages/index.tsx

The page exports server mode, revalidation, tags, loader data and SSR markup.

Function route

src/api/health.ts

The health API declares serverless compute and returns JSON through the Vura reply object.

Private request-time snapshot

src/pages/snapshot.tsx

The snapshot reads fresh loader data without public revalidation, contrasting the cached overview.

Build guide

src/pages/build.tsx

The public guide documents useLoaderData, literal head strings and local CSS delivery checks.

Second incident server route

src/pages/incidents/webhook-retry-spike.tsx

Literal server configuration and a typed loader make the second advertised incident directly addressable.

Responsive application stylesheet

src/site/styles.css

The source stylesheet supplies readable status copy, 44px navigation and contained monospace readouts.

Code patterns worth copying

Declare a cached server-rendered page

src/pages/index.tsx

The cache contract is near the page, not hidden in deployment notes.

const { renderedAt, summary } = useLoaderData<typeof loader>();

Keep serverless route metadata literal

src/api/health.ts

Vura can see the route shape statically while the handler stays a small typed function.

compute: { class: 'function', memory: '1gb' },

Read the incident from its loader contract

src/pages/incidents/webhook-retry-spike.tsx

The component renders shared incident detail from real loader data rather than guessing page props.

const { incident, renderedAt } = useLoaderData<typeof loader>();

Use the shared stylesheet on application routes

src/site/styles.css

The source stylesheet supplies readable status copy, 44px navigation and contained monospace readouts.

.brand { display: inline-flex; align-items: center; min-height: 44px; gap: 8px; text-decoration: none; font-weight: 700; font-size: 1.25rem; letter-spacing: -.02em; }

Real issues and fixes

The Vura page scanner needs literal exports

Problem
If page config is computed indirectly, the build cannot reliably classify routes, cache tags or function shape.
Fix
Signal keeps page and route exports as literal objects next to their handlers.
Proof
The starter build can emit server, cache and function metadata from source inspection.
Takeaway
For deployable metaframework features, explicit route metadata beats clever abstraction.

Loader data is not passed as ordinary page props

Problem
Overview, incident and snapshot pages first expected loader return values as top-level props, so public UI could show fallback or unknown values instead of proving render timing.
Fix
Import useLoaderData from @celsian/vura-core and read the typed loader result inside each page component.
Proof
The cached overview renders its ISO timestamp through useLoaderData, while the snapshot route reads a fresh health payload per request.
Takeaway
Server-rendered Vura pages should read request data through the framework loader hook, not guessed component props.

Escaped head newlines rendered as visible text

Problem
A literal head string containing escaped newline text could leak visible \n characters into the page.
Fix
Keep head metadata as single-line literal strings and explain the constraint on /build.
Proof
The current index, snapshot, build and 404 pages use single-line head strings; the public guide shows the before/after.
Takeaway
When static scanners require literal strings, boring one-line metadata can be the safest output contract.

Every advertised incident needs a real route

Problem
The second bundled active incident linked to 404 because no detail page existed.
Fix
Add a literal server-page definition for webhook-retry-spike, read its loader through useLoaderData and share facts/timeline rendering with the ingestion incident.
Proof
Browser tests visit both incident details while retaining CSS delivery, actual loader stamps and cached-versus-private snapshot assertions.
Takeaway
Direct-route completeness is part of the content contract, even when a dashboard already lists the record.

What went smoothly

  • Literal page exports make rendering mode and cache tags visible to both Vura and readers.
  • The render proof timestamp gives a simple way to observe cached versus uncached behavior.
  • Local smoke now checks /styles.css returns 200 text/css so public pages do not silently ship as unstyled defaults.
  • The new incident reused shared timeline rendering and literal page configuration; source changes do not themselves prove a new hosted release.
  • Server-rendered overview and incident routes share the source stylesheet and synchronized public copy while loader and cache behavior remain unchanged.

Boundaries to preserve

  • Status data is fictional seed data.
  • The server-render proof demonstrates cache behavior; it is not an uptime monitor.

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

    Both incident detail routes render, request loaders use real timestamps and the stylesheet is served correctly. Cached overview and private uncached snapshot behavior passed live proof.

  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

    Adding the missing detail route for the second active incident while preserving verified loader and cache behavior. The current source and deployment links still identify the previous verified release.

  5. · Live on Vura

    Live corrections verified after independent follow-up

    The hosted stylesheet is restored and the page uses the documented loader-data hook. CSS, real ISO stamps, cached overview reuse and private uncached snapshots passed independent live checks.

  6. · Live on Vura

    Design refinement released for live workflow review

    The hosted stylesheet is restored and the page uses the documented loader-data hook. CSS, real ISO stamps, cached overview reuse and private uncached snapshots passed independent live checks.

  7. · Live on Vura

    Live audit found a public-asset delivery gap

    The same build serves its public stylesheet locally, while the hosted CDN omits it. A paired fix will publish public assets through both upload paths and read page loader data through the documented API. Regression and hosted checks are required before calling this repaired.

  8. · 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.

  9. · 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.

  10. · 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.

  11. · 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.

  12. · 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.

  13. · 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.

  14. · 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.

  15. · Building

    Implementation started

    The standalone project files exist and the product build is active. No local verification or live release is claimed yet.

  16. · 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