Goshtoso

Application recipes

Compose product surfaces, not component piles

Four server-rendered recipes show how Goshtoso components become durable application structure. Each recipe separates reusable UI from the routing, policy, queries, and domain state that belong to your app.

01

App Shell

Give every task a stable place to start.

Production workspace

Operations overview

Monitor the release train and respond to active changes.

All systems nominal

Needs attention

payments-api

Updated moments ago

Ready for approval

identity-worker

Updated moments ago

Deploying

docs-site

Updated moments ago

Healthy

Problem

Repeated page chrome drifts quickly. The shell must own global navigation, responsive positioning, identity, and page framing while each route supplies only its task content.

Goshtoso components

  • Navbar Global brand, primary navigation, account menu, and compact actions.
  • Sidebar Persistent desktop navigation and current-route orientation.
  • Button One decisive global action with familiar states.
  • Badge Compact environment and system-state signals.

States to design

  • Known route with one active navigation item.
  • Mobile navigation open and closed.
  • Account menu open, signed-out state, and restricted actions.
  • Slow or failed route content without losing the shell.

What stays app-specific

  • Route tree, authorization, workspace selection, and account actions.
  • Which content is global, route-scoped, streamed, or cached.
  • Breakpoints driven by the app's real labels and navigation depth.

At 390 px

Keep the navbar and page title. Replace the persistent sidebar with the Navbar mobile menu or Sidebar Overlay. Stack page actions below identity and preserve one page scrollbar.

At 1440 px

Hold the navbar at the top, reserve a stable sidebar column, and let the task region grow. Secondary context may use a right rail when it does not compete with the primary task.

Accessibility

  • Name header, navigation, main, and complementary landmarks.
  • Expose the current route with aria-current and keep focus visible after navigation.
  • Return focus to the mobile navigation trigger after dismissal.

Done when

  • Direct navigation and fragment navigation produce the same active state.
  • At 390 px, no persistent sidebar or second page scrollbar remains.
  • At 1440 px, the content region does not jump between routes.
  • Keyboard users can open, traverse, and close every global control.
Source map 
components/navbar        -> global navigation and account actions
components/sidebar       -> desktop navigation and mobile overlay
components/button        -> shell-level primary action
components/badge         -> environment and health signals
app/ui/shell.templ       -> responsive composition and landmarks
app/navigation.go        -> routes, labels, permissions, active state

02

Operations List

Help operators scan, narrow, select, and act without losing context.

Release control

Deployments

Three changes need review before the next window closes.

3 awaiting review
Deployments awaiting operational review
ServiceReleaseEnvironmentStatusOwnerActions
payments-api Critical path
v2.18.0ProductionAwaiting approvalLena Ortiz
identity-worker Background service
v4.3.1ProductionDeployingMaya Chen
docs-site Public edge
v1.42.2StagingReadySam Rivera

Showing 3 of 18 deployments. Selection remains stable while filters update from the server.

Problem

Operational lists fail when filters, selection, status, and row actions are designed separately. Compose them as one server-backed task with explicit query and selection ownership.

Goshtoso components

  • Table Rows, accessible caption, selection, sorting, pagination, and HTMX updates.
  • Text Input Search with a persistent label and server query value.
  • Select Bounded filters with a visible current value.
  • Badge Text-backed semantic status in dense rows.
  • Button Create, clear, review, and bulk actions.

States to design

  • Initial, filtered, sorted, selected, and paginated results.
  • Skeleton loading, empty results, query error, and stale result recovery.
  • Zero, one, and many selected rows with valid bulk actions.
  • Row action pending, completed, and rejected by the server.

What stays app-specific

  • Query grammar, filter defaults, column priority, and row permissions.
  • Selection persistence across pages and safety rules for bulk actions.
  • HTMX endpoints, optimistic behavior, audit logging, and export jobs.

At 390 px

Stack the title, count, and primary action. Put filters in a single column, keep the table horizontally scrollable, and preserve the identifying column before secondary metadata.

At 1440 px

Keep the toolbar on one scan line when labels fit. Use the full width for the table, align status and actions predictably, and paginate in the same content region.

Accessibility

  • Provide a specific table caption and labels for every filter.
  • Do not encode status by color alone. Keep visible text in every Badge.
  • Announce result-count changes and preserve focus when HTMX swaps rows.

Done when

  • Search, filters, sorting, and pagination round-trip through canonical URLs.
  • Selection remains understandable after a server-rendered row swap.
  • Empty, loading, error, and permission states are as usable as the populated list.
  • The 390 px path preserves identity, action labels, and keyboard reachability.
Source map 
components/table         -> row structure, selection, sorting, pagination
components/textinput     -> search query
components/select        -> bounded filters
components/badge         -> row status
components/button        -> create, row, and bulk actions
app/deployments/query.go -> filter parsing and result counts
app/deployments/list.templ -> toolbar, columns, empty and error states

03

Detail Workspace

Keep identity, status, actions, and deeper context in one navigable workspace.

payments-api v2.18.0

Awaiting approval

Production rollout with a guarded database migration and automatic rollback threshold.

Strategy
10% canary, then progressive rollout
Rollback signal
Error rate above 1.5%

Twelve reviewed changes are included in this release.

  • Add idempotency keys to capture requests.
  • Backfill the settlement ledger in batches.
  • Remove the deprecated retry flag.
  1. Sam completed the security review.
  2. Lena attached the rollback runbook.
  3. Automation passed all preflight checks.

Problem

A detail route must answer what this is, what state it is in, what can happen next, and where deeper evidence lives without forcing users through separate pages.

Goshtoso components

  • Breadcrumbs Hierarchy and a reliable path back to the parent list.
  • Tabs Keyboardable views of overview, changes, and activity.
  • Badge Current lifecycle state next to the resource identity.
  • Alert Decision-critical context before the primary action.
  • Button Primary and secondary resource actions.

States to design

  • Loading identity, complete detail, not found, and access denied.
  • Action available, pending, failed, completed, or revoked by new state.
  • Tabs with populated, empty, lazy-loaded, and error content.
  • Concurrent update detected with an explicit refresh path.

What stays app-specific

  • Resource identity, lifecycle transitions, permissions, and destructive-action policy.
  • Which tab owns URL state and which panels may lazy load.
  • Freshness, conflict detection, activity provenance, and audit detail.

At 390 px

Wrap breadcrumbs, stack actions below the title, keep tabs horizontally scrollable, and move the context rail below the active panel.

At 1440 px

Keep identity and actions on one header line when possible. Reserve the main column for tab content and a narrow rail for stable metadata, never for a competing task.

Accessibility

  • Keep the h1, status text, and primary action in a predictable reading order.
  • Use the Tabs arrow-key behavior and visible focus instead of custom tab controls.
  • Move focus to validation or server feedback after a destructive action fails.

Done when

  • The route communicates identity, status, and next action before the first tab.
  • Refreshing or deep-linking restores the correct resource and tab.
  • Actions remain correct when permissions or resource state change.
  • At both target widths, context follows the task instead of competing with it.
Source map 
components/breadcrumbs   -> parent hierarchy
components/tabs          -> detail views and keyboard navigation
components/badge         -> lifecycle state
components/alert         -> decision-critical context
components/button        -> resource actions
app/releases/detail.go   -> resource query, permissions, transitions
app/releases/detail.templ -> header, tab panels, context rail

04

Multi-step Workflow

Make progress, validation, review, and recovery explicit.

  1. completed
    Basics
  2. 2
    Targets
  3. 3
    Review

Step 2 of 3

Choose deployment targets

Select where this release can run and define the rollout limit.

Start between 1 and 25 percent.
Stop the rollout when the error threshold is crossed.

Problem

Long forms hide progress and make recovery expensive. A workflow should expose the current step, validate on the server, preserve safe draft data, and present a final review before commitment.

Goshtoso components

  • Steps Ordered progress with completed, current, and upcoming states.
  • Text Input Typed values, constraints, helper text, and validation feedback.
  • Select Constrained choices with an explicit label and current value.
  • Checkbox Optional policy choices with descriptive help.
  • Alert Draft, validation, and submission feedback.
  • Button Back, continue, retry, and final commit actions.

States to design

  • Pristine, editing, server validation error, and valid step.
  • Draft saving, saved, save failed, expired, and resumed.
  • Reviewing, submitting, completed, duplicate submit, and recoverable failure.
  • Back navigation with preserved values and corrected downstream state.

What stays app-specific

  • Step graph, validation rules, draft lifetime, ownership, and idempotency keys.
  • Which changes invalidate later steps and how resumed sessions are reconciled.
  • Final side effects, audit records, retries, and cancellation policy.

At 390 px

Use a compact vertical progress summary before the active form. Stack fields and actions, keep Back before Continue in reading order, and avoid a second internal scroller.

At 1440 px

Use a narrow progress rail and a focused form column. Keep helper text close to fields and place actions at the form boundary, not at the viewport edge.

Accessibility

  • Mark the current step with aria-current and announce server-rendered progress changes.
  • Associate helper and error text with fields and focus the first invalid control.
  • Prevent duplicate submission while keeping the pending state understandable.

Done when

  • Every step can render directly from server state after a refresh.
  • Back and resume preserve valid values without keeping invalid downstream decisions.
  • Errors identify the field or action that needs attention and move focus there.
  • The final commit is idempotent and its completion state survives retries.
Source map 
components/steps         -> progress and current-step semantics
components/textinput     -> typed fields and validation
components/select        -> constrained choices
components/checkbox      -> optional policy choice
components/alert         -> draft and submission feedback
components/button        -> workflow navigation
app/workflow/state.go    -> step graph, draft, validation, idempotency
app/workflow/page.templ  -> step form, review, success and recovery

Field-proven extensions

Patterns recovered from independent apps

Three blind consumer builds pushed the four base recipes into finance, warehouse, and editorial work. Reuse the decision structure; keep the domain voice.

Decision Queue

Operations List + Detail Workspace

Keep the queue, selected record, risk or policy context, decision form, and audit history visible together. Stack the selected record after the queue at 390 px.

Interruption-safe Workflow

Multi-step Workflow + bounded draft

Default the common case, edit exceptions only, review exact changes, preserve a short-lived draft, and make retries idempotent. Sticky actions must not cover focused fields.

Content-first Review

Queue + reading surface + decision rail

Let typography and rhythm belong to the publication. Keep author, deadline, channel, status, and handoff note next to the decision instead of converting prose into dashboard cards.