Skip to content
← All starter build updates

Portfolio starter

Form

An architecture studio portfolio centered on spaces, projects and material details.

Live on VuraUpdated

Case studies now explain program, material and design rationale, and a selected study can seed an empty brief without overwriting edits. Drawings and the vermillion drafting identity remain intact.

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

Build-time rendered public content with client-mounted interactive islands.

Learning journal

How to read this starter

Form is a static architecture-portfolio starter with project detail pages, a filter island and a local proposal-brief generator.

Source map

Server renderer

src/server/render.mjs

Project pages and static routes render with h() and renderToString().

Client islands

src/client/main.jsx

Filter and proposal islands mount over static fallback sections.

Static build

scripts/build.mjs

The build writes route aliases, assets, sitemap, robots and manifest.

Browser smoke

scripts/smoke.mjs

The smoke verifies filters, proposal persistence, denied storage, keyboard download activation and real 404.

Contextual case-study records

src/content.mjs

Project records include program, materials, rationale and tradeoffs; known study slugs can seed a local proposal.

Responsive application stylesheet

src/styles.css

Case and brief grids align to the start; navigation and form controls retain 44px targets.

Code patterns worth copying

Keep a local proposal preview computed

src/client/main.jsx

No separate preview state is needed; edits write source fields and the proposal text derives from them.

const output = useComputed(() => `FORM PROPOSAL BRIEF\n\nClient: ${client()}\nSite: ${site()}\nScope: ${scope()}\nBudget: ${budget()}\n\nPrepared locally. Not submitted to a studio.`);

Verify accessible activation when pointer layout is dense

src/client/main.jsx

The regression uses keyboard activation so the primary action remains testable even when mobile composition is tight.

const blob = new Blob([output()], { type: 'text/plain' });

Resolve study context without overwriting saved edits

src/client/main.jsx

Known study context seeds an empty editor. A saved brief remains until an explicit Use study brief action replaces it.

const study = data.projects.find(project => project.slug === new URLSearchParams(location.search).get('study'));

Use the shared stylesheet on application routes

src/styles.css

Case and brief grids align to the start; navigation and form controls retain 44px targets.

.case { display: grid; grid-template-columns: minmax(0, 1fr) minmax(0, 1fr); align-items: start; gap: 48px; margin-block: 48px; }

Real issues and fixes

A compact form still needs breathing room below controls

Problem
The proposal editor was functionally correct but cramped where the generated preview and status copy met the controls.
Fix
Keep the computed preview, then use spacing and a keyboard-activated download proof instead of adding new state or abstractions.
Proof
Smoke focuses Download brief, presses Enter, and verifies the live status names form-proposal-brief.txt.
Takeaway
When the state model is already clean, a design repair can stay in layout and proof rather than code architecture.

Client mount replaces static fallback content

Problem
The proposal route starts as static fallback HTML, then the island replaces that region when JavaScript loads.
Fix
Keep fallback copy useful, keep browser JSX in the client entry and document that mount is enhancement, not SSR-preserving hydration.
Proof
The smoke test exercises the mounted proposal editor and reload persistence from the generated static artifact.
Takeaway
Do not describe these islands as hydrated server markup; they are client-mounted interactive regions.

A case-study action lost its context

Problem
Draft a proposal opened a generic brief instead of carrying the selected project; longer previews also exposed grid overflow.
Fix
Resolve the study query against embedded records, preserve saved fields, and offer explicit context application. Add program/material/rationale content; reset figure margins and let preview children shrink and wrap.
Proof
Product-depth tests require complete study records; browser checks verify contextual seed, preserved edits, text download, useful no-JS fallback and 390px layout.
Takeaway
Contextual entry should seed empty work, not silently replace an existing draft.

What went smoothly

  • Original SVG studies avoid external media while still giving each case study a visual identity.
  • The proposal output is a computed string, so preview and downloaded text stay in sync with field edits.
  • The proposal remained a computed projection of four signals; richer case-study context changed inputs without adding submission or lead-capture behavior.
  • Architectural SVG studies remain the main visual object while case-study and brief grids fit their own content and use the same local type scale as static pages.

Boundaries to preserve

  • Proposal data is local-only and never submitted to a CRM or server.
  • The portfolio content is fictional and has no analytics or lead capture endpoint.

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

    Case studies now explain program, material and design rationale, and a selected study can seed an empty brief without overwriting edits. Drawings and the vermillion drafting identity remain intact.

  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

    Deepening project materials, program and rationale and carrying a selected study into the brief. The current source and deployment links still identify the previous verified release.

  5. · Live on Vura

    Live corrections verified after independent follow-up

    Case studies align with the page shell, project cards have balanced composition and filter results retain their SVG study variants. Live project filtering passed.

  6. · Live on Vura

    Design refinement released for live workflow review

    Case studies align with the page shell, project cards have balanced composition and filter results retain their SVG study variants. Live project filtering passed.

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

    Implementation started

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

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