minutework 0.1.56 → 0.1.58

package/assets/claude-local/skills/vuilder-mode-b-hosted-and-spawn/SKILL.md

@@ -1,14 +1,24 @@
 ---
 name: vuilder-mode-b-hosted-and-spawn
-description: "Mode B Vuilder: run a hosted broker/demo on your operator runtime, let customers join via /_mw, and offer opt-in 'spawn my own runtime' later (configurable trigger). Use when customers try a hosted product before getting their own server."
+description: "Mode B Vuilder: run your own real product on your host runtime where your team and outside members work with full platform capability; a member can opt to 'create my own server' (mint), or a /_mw customer upgrades to their own runtime (promote)."
 ---
 
-# Vuilder Mode B: Hosted Broker/Demo + Opt-In Spawn
+# Vuilder Mode B: The Vuilder's Own Runtime + Opt-In "Create My Own Server"
 
-Use this skill when a generated Vuilder workspace runs a **hosted product** on
-its own operator runtime that customers consume first, and only **later** do
-those customers provision their **own** runtime. Read
-`vuilder-workspace-architecture/SKILL.md` first; this skill specializes it.
+Use this skill when a generated Vuilder workspace runs a **real product on the
+Vuilder's own runtime** — the Vuilder is a full MinuteWork tenant using the whole
+platform: their **own host runtime**, their **team collaborating there with the
+runtime's AI, agents, and threads over real records**, and outside users joining
+as **members** of that runtime with full platform capability. Later, a member (or
+a product-consumer customer) can opt to **create their own server** — a separate
+runtime of their own. Read `vuilder-workspace-architecture/SKILL.md` first; this
+skill specializes it.
+
+Mode B is **not whitelabeling and not a throwaway demo.** The Vuilder runs their
+own real tenant business; "hosted broker", "shared demo", and "shared workspace"
+are only *shapes* that business can take, never the definition. The point is that
+the Vuilder and their members work together on the platform with full capability
+(AI, agents, threads, records), and a member can graduate to their own server.
 
 This skill is vertical-neutral. FleetRun and Ostronaut appear only as clearly
 marked illustrative examples — never as platform behavior to hardcode.
@@ -16,150 +26,199 @@ marked illustrative examples — never as platform behavior to hardcode.
 ## Mode A vs Mode B — decide which you are
 
 - **Mode A (signup = auto-spawn).** A customer signs up on the Vuilder public
-  site and the platform immediately provisions a fresh customer tenant runtime
-  and installs the app pack. This is the default flow in
-  `vuilder-workspace-architecture` (`customer_vertical_signup`). Pick Mode A
-  when every customer needs their own isolated runtime from day one.
-- **Mode B (hosted broker/demo, then opt-in spawn).** The Vuilder runs a shared
-  hosted product on its **operator runtime**. Customers **join the host
-  runtime** via `/_mw` customer auth and use the product there (a broker, a
-  demo, a shared workspace). Each customer provisions their **own** runtime
-  **later**, as an explicit opt-in step — keeping their identity and history.
-  Pick Mode B when customers should try value before committing to their own
-  server, or when their own runtime should appear only once a condition holds.
+  site and the platform immediately provisions them a fresh runtime and installs
+  the app pack (`customer_vertical_signup`). Pick Mode A when every customer needs
+  their own isolated runtime from day one.
+- **Mode B (the Vuilder's own runtime first, then opt-in "create my own
+  server").** The Vuilder runs their **own real product** on their **host
+  runtime**. Their team and outside **members** work there with full platform
+  capability; some users may instead join only as **product-consumer customers**.
+  Later, a member or customer opts to **create their own server** — the platform
+  provisions a separate runtime for them and installs the Vuilder's published
+  pack, while they keep their place on the host runtime. Pick Mode B when people
+  should work on (or consume) the Vuilder's runtime before — or instead of —
+  standing up their own.
 
 > Illustrative only:
-> - *FleetRun* (insurance brokering): carriers sign up as customers of the
->   host runtime and opt to spawn their own runtime when they are ready.
-> - *Ostronaut* (retail conversation intelligence): stores try a hosted demo
->   and spawn their own runtime when real store data starts flowing.
+> - *FleetRun* (insurance brokering): carriers join the Vuilder's runtime and
+>   later create their own server when they are ready.
+> - *Ostronaut* (retail conversation intelligence): stores use the hosted product
+>   and create their own server when real store data starts flowing.
 >
 > Both are instances of the same vertical-neutral shape; do not copy their
 > vocabulary into schemas, manifests, or services.
 
-If signup must always provision a runtime, you want Mode A — stop here and use
-`vuilder-workspace-architecture`.
+If people must always get their own runtime at signup, you want Mode A — stop
+here and use `vuilder-workspace-architecture`.
+
+## Two join planes — member vs customer (decide which, or both)
+
+Mode B has **two distinct ways** an outside user joins the host runtime. They are
+different auth planes with different capability, and a Mode B product may use one
+or both. The member plane is the richer, collaboration-first shape.
+
+- **Member-plane join (full capability — the collaboration shape).** Outside
+  users are **invited as members** of the Vuilder's tenant: a platform
+  `Membership` reached through **SSO + the branded shell** (`vuilder-shell`,
+  `/w/[workspace_slug]`). Members get full platform capability — threads, agents,
+  AI, records — and work alongside the Vuilder's own team on the host runtime.
+  This is the "the Vuilder and outside members build/operate together with the
+  platform's AI" shape. See `shell-architecture/SKILL.md` and the identity
+  substrate below.
+- **Customer-plane join (product-consumer).** Users authenticate as
+  `tenant_customer` through same-origin **`/_mw`** on a `tenant-app` and consume a
+  bounded **hosted product surface** under `/app` (read/act through
+  `webCustomerExposed` query/action manifests). This is the "consume a hosted
+  product" shape, not full shell/member capability.
+
+Do not collapse Mode B into "`/_mw` only." Name which plane(s) your product uses;
+the member plane is the default for collaboration-first verticals.
 
 ## Surface shape (follow the Starter Choice Matrix; shell-first)
 
-- **`tenant-app`** hosts marketing, native `/_mw` customer signup/login, and the
-  hosted product under `/app`. Browser customer auth uses `@minutework/web-auth`
-  against same-origin `/_mw/auth/*`; the principal is `tenant_customer`. `/_mw`
-  only resolves on a **live, canonical** customer-web host — go live with
-  `minutework deploy --live`. See `tenant-app-customer-auth-deploy/SKILL.md`.
-- **The hosted broker/demo runs on the Vuilder's operator runtime**, not in the
-  browser. `/app` consumes it through `mw.query` / `mw.action` against
-  `webCustomerExposed` query/action manifests (see `app-pack-authoring/SKILL.md`
-  and `generated-workspace-architecture/SKILL.md`). Browser intake is untrusted:
-  it never chooses package refs, runtime providers, tenant ids, or install
+- **`vuilder-shell`** is the primary **member-plane** surface — the branded
+  member/operator shell (`/w/[workspace_slug]`) for the Vuilder's own team, for
+  invited members, and later for anyone who has their own server. Its `/login` is
+  an SSO handoff (see the `vuilder-workspace-architecture` hard boundary); the
+  shell never owns identity, provisioning, or app-pack install authority. See
+  `shell-architecture/SKILL.md`.
+- **`tenant-app`** is the **customer-plane** surface: marketing, native `/_mw`
+  customer signup/login, and the hosted product under `/app`. Browser customer
+  auth uses `@minutework/web-auth` against same-origin `/_mw/auth/*`; the
+  principal is `tenant_customer`. `/_mw` only resolves on a **live, canonical**
+  customer-web host — go live with `minutework deploy --live`. See
+  `tenant-app-customer-auth-deploy/SKILL.md`.
+- **The hosted product runs on the Vuilder's host runtime**, not in the browser.
+  `/app` consumes it through `mw.query` / `mw.action` against `webCustomerExposed`
+  manifests (see `app-pack-authoring/SKILL.md`,
+  `generated-workspace-architecture/SKILL.md`). Browser intake is untrusted: it
+  never chooses package refs, runtime providers, tenant ids, or install
   coordinates.
-- **`vuilder-shell`** remains the branded member/operator surface
-  (`/w/[workspace_slug]`) for the Vuilder's own operators and for customers once
-  they have their own runtime. See `shell-architecture/SKILL.md`. The hard
-  boundary still holds: the shell never owns identity, provisioning, or app-pack
-  install authority.
 
-## Shadow tenant + claim continuity
+## Identity before a member/customer has their own server
 
-A Mode B customer exists as identity **before** they have their own runtime:
+Members and customers exist as identity on the host runtime **before** they have
+their own server, and that identity carries over when they create one:
 
-- When a visitor/customer first appears, Core resolves a **shadow tenant** and a
-  **shadow person** for their external identity (e.g. email). The shadow person
-  is a stable participation anchor, owned by the shadow tenant. See
+- Core resolves a **shadow tenant** and **shadow person** for an external identity
+  (e.g. email) — a stable participation anchor. See
   `shadow-participation-and-guest-threads/SKILL.md`.
-- Joining the host runtime via `/_mw` creates a customer membership on the
-  **host** tenant. Claim refs tie that membership back to the customer's shadow
-  identity, so history is preserved across the later spawn.
-- The spawn is an **explicit claim/upgrade**, modeled as a real provisioning
-  step — never a silent mutation. The platform **promotes the customer's
-  existing tenant in place** rather than minting a fresh one, so there is no
-  duplicate identity and no orphaned history.
-
-Do not invent a parallel guest-account or per-customer identity model; reuse the
+- **Member-plane**: an invite creates a `Membership` on the host runtime, anchored
+  to the member's person; the member works through the shell with full capability.
+- **Customer-plane**: `/_mw` creates a `tenant_customer` membership on the host
+  runtime, anchored to the customer's shadow tenant.
+- In both planes, **claim refs tie the host membership back to the person's shadow
+  identity**, so identity and history are preserved when they later create their
+  own server. Creating a server is an **explicit claim/upgrade**, modeled as a
+  real provisioning step — never a silent mutation.
+
+Do not invent a parallel guest-account or per-user identity model; reuse the
 external-identity → shadow tenant → shadow person → claim substrate.
 
-## The opt-in spawn action + configurable trigger
+## Opt-in "create my own server" (spawn)
 
-Spawn is **product-driven, not hardcoded**. There are two ways to fire it; both
-target the same platform substrate (a `customer_runtime_spawn` onboarding intent
-that promotes the customer's tenant in place and installs the Vuilder's
-published app pack).
+"Create my own server" is **product-driven, not hardcoded.** ("Spawn" is the
+internal/platform term; the user-facing CTA is "create my own server / runtime.")
+There are two ways to *fire* it; both go through the platform's member/customer
+spawn substrate, which provisions a runtime and installs the Vuilder's published,
+attested pack.
 
-### 1. Explicit opt-in action (available now)
+### 1. Explicit "create my own server" action (available now)
 
-Wire a "create my own runtime" affordance in `/app` to the platform's customer
-spawn endpoint:
+Wire a "create my own server" affordance to the platform spawn endpoint:
 
-- The authenticated customer (`tenant_customer` session) POSTs to
+- A member fires it from the shell, or a `/_mw` customer POSTs to
   `/_mw/runtime/spawn` on the live host.
-- The platform gates on an **active, email-verified** customer membership,
-  resolves identity continuity, promotes the customer's tenant, and installs the
-  Vuilder's **published, attested** app pack. It is idempotent.
+- The platform gates on an **active, email-verified** membership, resolves
+  identity continuity, provisions the runtime, and installs the Vuilder's
+  **published, attested** app pack. It is idempotent.
 - The browser only signals intent. It never picks the package, runtime provider,
-  or tenant — the platform derives those from the host Vuilder + the customer's
-  verified identity.
-
-This is the FleetRun-style "customer opts in" trigger *(illustrative)*.
+  or tenant — the platform derives those from the host Vuilder + the verified
+  identity.
 
 ### 2. App-pack-declared condition (configurable trigger)
 
-To make spawn fire when a **product condition** holds rather than on a button
-press, declare the condition in the app pack instead of hardcoding it. Use the
-local event bus declaration surface (`event-bus/SKILL.md`): emit a
-product-defined event when the condition occurs, then declare an
-`eventSubscription` (with `filters`) whose target flow requests the spawn. Keep
-event types and field names vertical-neutral (they must pass `mw.E002`/`mw.E010`
-— no vertical role/identifier words).
-
-This is the Ostronaut-style "real data starts flowing" trigger *(illustrative)*:
-emit a generic "data received" event, filter for the threshold that means the
-customer is now operating for real, and let the subscription drive the spawn.
+To fire on a **product condition** instead of a button press, declare the
+condition in the app pack (do not hardcode it). Use the local event bus
+(`event-bus/SKILL.md`): emit a product-defined event, then declare an
+`eventSubscription` (with `filters`) whose target flow requests the server. Keep
+event types and field names vertical-neutral (`mw.E002`/`mw.E010` — no vertical
+role/identifier words).
 
 > Honesty note: the **declaration surface** (events, subscriptions, filters)
-> ships today, and the **explicit opt-in action** above is fully executable. The
-> automatic condition→spawn leg is delivered by platform substrate that is still
-> being rolled out (a generic emit site, the flow→spawn dispatch, and the
-> local-event dispatch flag). Until that lands in the target runtime, fall back
-> to the explicit opt-in action and keep the declared condition as the
-> product's source of truth. Do not assume auto-fire works without confirming it
-> in `runtime-capability-inventory`.
+> ships today, and the **explicit action** above is fully executable. The
+> automatic condition→spawn leg is platform substrate still being rolled out (a
+> generic emit site, the flow→spawn dispatch, and the local-event dispatch flag).
+> Until it lands, use the explicit action and keep the declared condition as the
+> product's source of truth. Confirm in `runtime-capability-inventory` before
+> assuming auto-fire works.
+
+## Mint-new vs promote-in-place — the two spawn semantics
+
+"Create my own server" has **two distinct tenant semantics, coupled to the join
+plane.** They are not interchangeable.
+
+- **Mint-new (member-plane — the primary path for this model; NOT built yet).** A
+  **member** of the Vuilder's host runtime clicks "create my own server" → the
+  platform **mints a fresh, separate tenant + runtime** for them and installs the
+  Vuilder's published pack. The member becomes the **owner** of their own server.
+  Their identity (shadow person / claim) carries over — they do not become a
+  different person — and they keep their **membership on the host runtime**
+  (multi-membership; see the server-switcher below). This is the "org admin stands
+  up their organization's own server" path.
+- **Promote-in-place (customer-plane — built today).** A `/_mw` customer who
+  already has a shadow (customer) tenant continues *as themselves* → the platform
+  **promotes their existing tenant in place** into a runtime-bearing tenant. This
+  is the "product-consumer upgrades to their own runtime" path. It **requires an
+  existing customer tenant and does not mint.**
+
+**Today only promote-in-place is executable:** `customer_runtime_spawn` requires
+an existing customer tenant and promotes it (it refuses to mint), and
+`customer_vertical_signup` (which does mint a fresh tenant) fires only from the
+**public signup site**, not the member plane. So the **member-plane → mint-new
+shape — the primary "member creates their own server" flow — is the open
+substrate gap to land**, not a secondary "maybe later." A proposed substrate
+change (a `spawn_mode: mint | promote` selector reachable from the member plane)
+is drafted for platform-team review.
+
+Until it lands, do not assume a member "create my own server" CTA mints a fresh
+separate tenant. Wire it to the promote-in-place path where that fits, or report
+the member-plane → mint-new need as a capability gap
+(`capability-gap-reporting/SKILL.md`). Confirm what shipped in
+`runtime-capability-inventory` before building against mint-new.
 
 ## Cross-runtime data continuity (scope honestly)
 
-After a customer spawns their own runtime, what carries over?
+After a member/customer creates their own server, what carries over?
 
 - **Identity and shared references re-anchor via ontology Core URNs.** Promote
-  local facts to shared `core_urn`s and re-anchor them on the spawned runtime
-  via the reviewable promotion loop. See `ontology-authoring/SKILL.md` and
-  `runtime_ontology_contract.md`. This is the supported continuity primitive.
-- **The spawn does not zero-copy the customer's host-runtime records into the
-  new runtime.** Ad-hoc record-level cross-runtime references (pointer + grant,
-  read at resolve time) are **not executable today**: `runtime_federation`
-  implements dataset publication + change-signal pub/sub only, and the
-  `bridge_protocol.md` hydrate path is design/spec, not built. So **a spawned
-  runtime cannot reference a specific record on the host runtime yet.** See
-  `federation_model.md` and `bridge_protocol.md`.
-- **Therefore scope the product to: spawn starts fresh; shared identity
+  local facts to shared `core_urn`s and re-anchor them on the spawned runtime via
+  the reviewable promotion loop (`ontology-authoring/SKILL.md`,
+  `runtime_ontology_contract.md`). This is the supported continuity primitive.
+- **Creating a server does not zero-copy host-runtime records into the new
+  runtime.** Ad-hoc record-level cross-runtime references (pointer + grant, read
+  at resolve time) are **not executable today**: `runtime_federation` implements
+  dataset publication + change-signal pub/sub only, and the `bridge_protocol.md`
+  hydrate path is design/spec, not built. So **a spawned runtime cannot reference
+  a specific record on the host runtime yet** (`federation_model.md`,
+  `bridge_protocol.md`).
+- **Therefore scope the product to: the new server starts fresh; shared identity
   re-anchors via ontology URNs; deep history reference is a follow-on once the
   federation record-reference primitive exists.** Do not promise zero-copy
-  history in product copy or design. If a Mode B product genuinely needs
-  record-level cross-runtime reads, report it as a capability gap
-  (`capability-gap-reporting/SKILL.md`) instead of inventing a copy-based
-  workaround.
+  history. If a Mode B product genuinely needs record-level cross-runtime reads,
+  report it as a capability gap rather than inventing a copy-based workaround.
 
 ## Server-switcher across host + spawned runtime
 
-After spawn, the customer holds **two memberships**: the customer membership on
-the Vuilder's host runtime and the owner membership on their own spawned
-runtime. Give them a way to switch between the hosted product and their own
-runtime:
+After creating their own server, the person holds **two memberships**: their place
+on the Vuilder's **host runtime** and the owner membership on their **spawned
+runtime**. Give them a way to switch:
 
 - Model this as multi-membership switching in the branded shell
   (`shell-architecture/SKILL.md`) — each membership opens its own
   `/w/[workspace_slug]` context; the shell never mixes their sessions.
-- The host membership stays valid after spawn (it is the continuity ledger), so
-  the customer can keep using the shared hosted product and their own runtime
-  side by side.
+- The host membership stays valid (it is the continuity ledger), so they can keep
+  using the Vuilder's host runtime and their own server side by side.
 - Identity stays single across both via the shared shadow/claim anchor; do not
   create a second identity for the spawned runtime.
 
@@ -167,18 +226,19 @@ runtime:
 
 - `vuilder-workspace-architecture` — the base Vuilder shape and the Mode A
   signup=auto-spawn flow this skill contrasts with.
-- `tenant-app-customer-auth-deploy` — make `/_mw` customer auth resolve on a
-  live canonical host.
+- `shell-architecture` — the member-plane branded shell, member work surfaces, and
+  multi-membership server switching.
+- `tenant-app-customer-auth-deploy` — make `/_mw` customer auth resolve on a live
+  canonical host (customer plane).
 - `shadow-participation-and-guest-threads` — shadow tenant/person + claim
-  continuity for pre-runtime customers.
+  continuity for pre-server members and customers.
 - `app-pack-authoring` and `generated-workspace-architecture` — `webCustomerExposed`
-  query/action manifests consumed by `/app` via `mw.query` / `mw.action`.
+  query/action manifests consumed by `/app`.
 - `event-bus` (and `dataset-subscriber-flow`) — declarative event/subscription
-  surface for the configurable spawn trigger.
-- `ontology-authoring` and `runtime_ontology_contract.md` — Core URN promotion
-  for cross-runtime identity continuity.
-- `shell-architecture` — branded shell + multi-membership server switching.
-- `federation_model.md` and `bridge_protocol.md` — what cross-runtime
-  federation does and does not support today (record-reference is a gap).
-- `capability-gap-reporting` — report record-level cross-runtime read needs
-  rather than working around them.
+  surface for the configurable "create server" trigger.
+- `ontology-authoring` and `runtime_ontology_contract.md` — Core URN promotion for
+  cross-runtime identity continuity.
+- `federation_model.md` and `bridge_protocol.md` — what cross-runtime federation
+  does and does not support today (record-reference is a gap).
+- `capability-gap-reporting` — report the member-plane → mint-new gap and
+  record-level cross-runtime read needs rather than working around them.

package/assets/claude-local/skills/vuilder-workspace-architecture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vuilder-workspace-architecture
-description: "First skill for generated Vuilder workspaces: vuilder-app public site, vuilder-shell branded customer shell, app-pack source, and the Mode A signup=auto-spawn flow. For hosted-demo-then-opt-in-spawn, see vuilder-mode-b-hosted-and-spawn."
+description: "First skill for generated Vuilder workspaces: vuilder-app public site, vuilder-shell branded shell, app-pack source, and the Mode A signup=auto-spawn flow. For the Vuilder's-own-runtime-first opt-in-spawn flow, see vuilder-mode-b-hosted-and-spawn."
 ---
 
 # Vuilder Workspace Architecture
@@ -17,13 +17,16 @@ acquisition flow:
 - **Mode A (signup = auto-spawn).** Signing up on the public site immediately
   provisions the customer their own tenant runtime and installs the app pack.
   This is the default this skill describes (see the Flow section below).
-- **Mode B (hosted broker/demo, then opt-in spawn).** The Vuilder runs a shared
-  hosted product on its own operator runtime; customers join it via `/_mw` and
-  use it there, then provision their OWN runtime later as an opt-in step (with a
-  configurable trigger). If customers should try a hosted product before getting
-  their own server, it is Mode B — **read
-  `vuilder-mode-b-hosted-and-spawn/SKILL.md`** and follow it instead of the Mode
-  A flow below.
+- **Mode B (the Vuilder's own runtime first, then opt-in "create my own
+  server").** The Vuilder runs their own real product on their **host runtime** —
+  their own tenant business. Outside users join either as **members** (full
+  capability — threads, agents, AI, records — via SSO + `vuilder-shell`) or as
+  **`/_mw` product-consumer customers**, work there, and later opt to **create
+  their own server** (the platform provisions them a separate runtime and installs
+  the Vuilder's pack). The hosted product can be a broker, shared workspace, or
+  demo — the shape does not change the lane; the member plane is the
+  collaboration-first default. **Read `vuilder-mode-b-hosted-and-spawn/SKILL.md`**
+  and follow it instead of the Mode A flow below.
 
 ## Default Workspace Shape
 
@@ -93,6 +96,7 @@ billing policy, or install coordinates.
   marketplace publish output.
 - Use `generated-workspace-architecture` for general local workspace trust
   boundaries.
-- Use `vuilder-mode-b-hosted-and-spawn` when the Vuilder runs a hosted
-  broker/demo customers join first and lets them spawn their own runtime later
-  (Mode B), instead of the Mode A signup=auto-spawn flow above.
+- Use `vuilder-mode-b-hosted-and-spawn` when the Vuilder runs their own real
+  product on their host runtime that outside users join as members (or `/_mw`
+  customers), and later lets them create their own server (Mode B), instead of
+  the Mode A signup=auto-spawn flow above.

package/assets/claude-local/skills/workspace-guidance-refresh/SKILL.md

@@ -23,6 +23,12 @@ does not match the current MinuteWork CLI export.
   - `mcp/claude-desktop.sample.json`
 - It does not regenerate tenant code, sidecar code, schema files, or arbitrary
   user-owned files outside the managed export set.
+- It never touches the authored overlays `CLAUDE.workspace.md`,
+  `AGENTS.workspace.md`, or `skills.workspace/**`. Those files sit alongside the
+  managed guidance but are intentionally outside the managed manifest, so
+  workspace-specific customizations survive every sync (including `--force`) with
+  no conflicts. Put workspace-specific guidance and authored skills there rather
+  than editing the managed `CLAUDE.md` / `AGENTS.md` / `skills/`.
 - If the workspace uses an older exported skill set, prefer refreshing assets
   before concluding that a Builder capability or instruction is missing.
 - If the workspace lacks sandbox/tier guidance for `minutework sandbox create`,

package/assets/templates/vuilder-public-site/src/app/globals.css

@@ -53,6 +53,38 @@ a {
   max-width: 760px;
 }
 
+.hero-with-media {
+  grid-template-columns: minmax(0, 0.95fr) minmax(280px, 0.85fr);
+  max-width: none;
+  align-items: center;
+}
+
+.hero-copy {
+  display: grid;
+  gap: 24px;
+}
+
+.hero-media,
+.section-image,
+.feature-image {
+  overflow: hidden;
+  border: 1px solid var(--line);
+  background: var(--surface);
+}
+
+.hero-media {
+  aspect-ratio: 4 / 3;
+}
+
+.hero-media img,
+.section-image img,
+.feature-image img {
+  display: block;
+  width: 100%;
+  height: 100%;
+  object-fit: cover;
+}
+
 .eyebrow {
   margin: 0;
   color: var(--accent);
@@ -96,8 +128,71 @@ p {
   padding: 24px;
 }
 
+.content-section,
+.cta-banner {
+  display: grid;
+  grid-template-columns: minmax(0, 0.9fr) minmax(240px, 0.7fr);
+  gap: 32px;
+  align-items: center;
+  margin-top: 56px;
+  padding-top: 56px;
+  border-top: 1px solid var(--line);
+}
+
+.content-section h2,
+.cta-banner h2 {
+  margin: 0;
+  font-size: clamp(2rem, 5vw, 4rem);
+  line-height: 1;
+}
+
+.section-image {
+  aspect-ratio: 4 / 3;
+}
+
+.feature-grid {
+  display: grid;
+  grid-template-columns: repeat(auto-fit, minmax(190px, 1fr));
+  gap: 16px;
+  margin-top: 28px;
+}
+
+.feature-item {
+  border: 1px solid var(--line);
+  background: var(--surface);
+  padding: 18px;
+}
+
+.feature-item h3 {
+  margin: 14px 0 0;
+  font-size: 1rem;
+}
+
+.feature-item p {
+  margin-bottom: 0;
+  font-size: 0.95rem;
+}
+
+.feature-image {
+  aspect-ratio: 16 / 10;
+}
+
 .site-footer {
   padding: 32px 0;
   border-top: 1px solid var(--line);
   color: var(--muted);
 }
+
+@media (max-width: 760px) {
+  .site-header {
+    align-items: flex-start;
+    gap: 16px;
+    flex-direction: column;
+  }
+
+  .hero-with-media,
+  .content-section,
+  .cta-banner {
+    grid-template-columns: 1fr;
+  }
+}