936 lines
41 KiB
TypeScript
936 lines
41 KiB
TypeScript
import { useMemo } from 'react'
|
|
import { Link } from 'react-router-dom'
|
|
import { MarketingShell } from '../components/layout/MarketingShell'
|
|
import { SiteMetadata } from '../components/seo/SiteMetadata'
|
|
import { OperationalStatusCallout } from '../components/ui/OperationalStatusCallout'
|
|
import { ProductSurfaceMatrix } from '../components/ui/ProductSurfaceMatrix'
|
|
import { PublicLaunchStatus } from '../components/ui/PublicLaunchStatus'
|
|
import { ReleaseValidationSummary } from '../components/ui/ReleaseValidationSummary'
|
|
import { paddleReadyDescription } from '../site-config'
|
|
import { buildReleaseMetadataItems, resolveReleaseCommerceView } from '../release-manifest'
|
|
import { buildLoginPath, buildProtectedDownloadPath, buildSupportPath } from '../site-routes'
|
|
import {
|
|
desktopFirstLaunchCards,
|
|
desktopDownloadSteps,
|
|
desktopReleaseSignals,
|
|
digitalDeliveryCards,
|
|
distributionDoctrineCards,
|
|
inputAndDevicePostureCards,
|
|
openSourceNotices,
|
|
operatorManualTracks,
|
|
privacyBoundaryCards,
|
|
productSurfaceMatrixRows,
|
|
releaseRolloutChecklist,
|
|
runtimeControlGuideCards,
|
|
supportEscalationCards,
|
|
termsBoundaryCards,
|
|
} from '../site-data'
|
|
import {
|
|
BulletCardSection,
|
|
BrowserAuthMethodsSection,
|
|
BrowserDesktopRealitySection,
|
|
DeliverySurfaceResponsibilitiesGrid,
|
|
DownloadableOperatorManualSection,
|
|
explorerFallbackPlan,
|
|
HigherDimensionalRuntimeGuideSection,
|
|
OperatorDesktopQuickstartSection,
|
|
operatorFallbackPlan,
|
|
PlanActionLink,
|
|
PublicPackagedDesktopProofSection,
|
|
PublicManualRouteAtlasSection,
|
|
PublicReleaseDecisionGuideSection,
|
|
ReleaseAuthorityBundleSection,
|
|
releaseCommerceFallback,
|
|
Section,
|
|
SimulatorManualSection,
|
|
StepCardSection,
|
|
studioFallbackPlan,
|
|
SurfaceChoiceGuideSection,
|
|
usePublicReleaseManifestView,
|
|
} from './public-page-helpers'
|
|
|
|
export function PricingPage() {
|
|
const { releaseManifestQuery, releaseManifest, windowsValidationPlatform } = usePublicReleaseManifestView('public-pricing')
|
|
const releaseCommerce = useMemo(
|
|
() => resolveReleaseCommerceView(releaseManifestQuery.data?.manifest, releaseCommerceFallback),
|
|
[releaseManifestQuery.data?.manifest],
|
|
)
|
|
const runtimePlanCatalog = useMemo(() => ([
|
|
explorerFallbackPlan,
|
|
{
|
|
...operatorFallbackPlan,
|
|
price: releaseCommerce.plan_price_operator,
|
|
ctaLabel: releaseCommerce.operator_checkout_url ? 'Open Paddle checkout' : operatorFallbackPlan.ctaLabel,
|
|
ctaHref: releaseCommerce.operator_checkout_url || operatorFallbackPlan.ctaHref,
|
|
},
|
|
{
|
|
...studioFallbackPlan,
|
|
price: releaseCommerce.plan_price_studio,
|
|
ctaLabel: releaseCommerce.studio_checkout_url ? 'Open Paddle checkout' : studioFallbackPlan.ctaLabel,
|
|
ctaHref: releaseCommerce.studio_checkout_url || studioFallbackPlan.ctaHref,
|
|
},
|
|
]), [releaseCommerce])
|
|
|
|
return (
|
|
<>
|
|
<SiteMetadata
|
|
title="HyperTwist pricing"
|
|
description="View HyperTwist browser-access, operator, and studio pricing with Paddle-ready checkout posture and launch-honest download/legal guidance."
|
|
canonicalPath="/pricing"
|
|
/>
|
|
<MarketingShell
|
|
eyebrow="Paddle-ready plans"
|
|
title="Pricing that matches the actual delivery model."
|
|
lede="The browser shell handles account, release, and billing access. The simulator remains desktop-first. Prices and checkouts can be switched live through HyperTwist's own Paddle-ready runtime commerce structure."
|
|
>
|
|
<Section title="Plan lineup" description={paddleReadyDescription}>
|
|
<div className="card-grid card-grid--pricing">
|
|
{runtimePlanCatalog.map((plan) => (
|
|
<article key={plan.key} className="card card--pricing">
|
|
<p className="status-pill">{plan.name}</p>
|
|
<h3>{plan.price}</h3>
|
|
<p>{plan.notes}</p>
|
|
<ul className="list">
|
|
{plan.features.map((feature) => (
|
|
<li key={feature}>{feature}</li>
|
|
))}
|
|
</ul>
|
|
<PlanActionLink href={plan.ctaHref} label={plan.ctaLabel} />
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<Section title="Launch posture">
|
|
<PublicLaunchStatus />
|
|
</Section>
|
|
|
|
<PublicPackagedDesktopProofSection
|
|
platform={windowsValidationPlatform}
|
|
actions={[
|
|
{ to: '/download', label: 'Open download center' },
|
|
{ to: '/open-source-notices', label: 'Review notices' },
|
|
]}
|
|
/>
|
|
|
|
<ReleaseAuthorityBundleSection
|
|
releaseManifest={releaseManifest}
|
|
description="Pricing is a distribution surface, so its launch truth should carry the same docs, release, source, and escalation bundle as the rest of the public release lane."
|
|
/>
|
|
|
|
<BrowserAuthMethodsSection
|
|
description="Pricing decisions are safer when the current shared-auth sign-in lineup is visible before checkout, protected release access, or browser-account follow-through."
|
|
/>
|
|
|
|
<StepCardSection
|
|
title="What happens after access is granted"
|
|
description="Pricing only stays professional when it explains the real path from browser entitlement into the packaged simulator instead of stopping at the checkout button."
|
|
cards={operatorManualTracks.slice(0, 3)}
|
|
/>
|
|
|
|
<SimulatorManualSection
|
|
title="What the software actually does after access is granted"
|
|
description="Plans only make sense if the public pricing lane also says what the entitled desktop software is for once it is installed."
|
|
/>
|
|
|
|
<HigherDimensionalRuntimeGuideSection
|
|
title="Higher-dimensional families behind the plans"
|
|
description="This keeps commercial copy tied to the real runtime families the desktop product already owns instead of leaving serious capability buried elsewhere in the manual."
|
|
/>
|
|
|
|
<BulletCardSection
|
|
title="Current input and runtime control truth"
|
|
description="The pricing page should also be explicit about the present control quality bar so buyers can see what is real today and what still remains gated."
|
|
cards={[...inputAndDevicePostureCards, ...runtimeControlGuideCards]}
|
|
/>
|
|
|
|
<SurfaceChoiceGuideSection description="This keeps pricing honest about what should happen next: stay public for plan comparison, move protected for account-aware access, and move native for the actual simulator." />
|
|
|
|
<PublicReleaseDecisionGuideSection
|
|
releaseManifest={releaseManifest}
|
|
description="Pricing should also say plainly whether the next honest operator move is checkout, protected desktop access, browser/account continuity, or notices/source follow-through."
|
|
/>
|
|
|
|
<BrowserDesktopRealitySection />
|
|
|
|
<Section
|
|
title="Why plans live in the browser while training stays native"
|
|
description="Commercial access, entitlement, and launch-readiness posture belong to the browser shell so the simulator can stay focused on training quality."
|
|
>
|
|
<DeliverySurfaceResponsibilitiesGrid limit={3} />
|
|
</Section>
|
|
|
|
<BulletCardSection
|
|
title="Commercial distribution doctrine"
|
|
description="Commercial pages should stay as explicit about release and legal posture as the rest of the public site."
|
|
cards={distributionDoctrineCards}
|
|
/>
|
|
|
|
<BulletCardSection
|
|
title="Terms of access in practice"
|
|
description="Pricing is easier to trust when the access model, simulator boundary, and operator obligations stay visible before checkout."
|
|
cards={termsBoundaryCards}
|
|
/>
|
|
|
|
<Section title="Important launch note">
|
|
<article className="callout">
|
|
<p>
|
|
Public pricing, checkout, and download pages are distribution surfaces. Before external launch,
|
|
keep their legal footer and open-source notices link live and ensure the corresponding-source URL is configured for any downloadable build containing MPL-covered material.
|
|
</p>
|
|
</article>
|
|
</Section>
|
|
</MarketingShell>
|
|
</>
|
|
)
|
|
}
|
|
|
|
export function DownloadPage() {
|
|
const { releaseManifestQuery, releaseManifest, windowsValidationPlatform } = usePublicReleaseManifestView('public-download')
|
|
|
|
return (
|
|
<>
|
|
<SiteMetadata
|
|
title="Download HyperTwist desktop"
|
|
description="Download the HyperTwist desktop build, preserve your target platform into the protected release surface, and pair the installed app with your browser account."
|
|
canonicalPath="/download"
|
|
/>
|
|
<MarketingShell
|
|
eyebrow="Desktop distribution"
|
|
title="Download the desktop build and pair it with your browser account."
|
|
lede="The website provides account, release, and legal surfaces. The actual simulator ships through the desktop lane, with package validation and release discipline carried over from the HyperTwist roadmap."
|
|
>
|
|
{releaseManifestQuery.isLoading ? (
|
|
<Section title="Release manifest status">
|
|
<article className="callout">
|
|
<p>Loading the current server-backed release manifest. Static preview metadata remains visible until the live manifest arrives.</p>
|
|
</article>
|
|
</Section>
|
|
) : null}
|
|
|
|
{releaseManifestQuery.isError ? (
|
|
<Section title="Release manifest status">
|
|
<OperationalStatusCallout
|
|
badge="Public release fallback"
|
|
title="The live release manifest could not be loaded from the auth server right now."
|
|
summary="This page is showing bounded fallback site metadata instead of current runtime release authority, and direct package delivery stays intentionally withheld until that authority returns."
|
|
sections={[
|
|
{
|
|
title: 'What still works',
|
|
items: [
|
|
'Supported targets, packaged proof, and public rollout guidance remain visible.',
|
|
'Platform selection can still be preserved into the protected sign-in and download handoff.',
|
|
],
|
|
},
|
|
{
|
|
title: 'What stays intentionally withheld',
|
|
items: [
|
|
'Raw desktop delivery URLs remain behind the protected release lane.',
|
|
'This public page does not claim live entitled release authority while the auth server is unavailable.',
|
|
],
|
|
},
|
|
{
|
|
title: 'Recommended recovery order',
|
|
items: [
|
|
'Use the protected dashboard once the auth server recovers if you need actual package delivery.',
|
|
'Open operator support if release-authority fallback persists during rollout or purchase work.',
|
|
],
|
|
},
|
|
]}
|
|
actions={[
|
|
{ label: 'Open protected downloads', to: buildProtectedDownloadPath('windows') },
|
|
{ label: 'Open support', to: buildSupportPath('operator-access') },
|
|
]}
|
|
/>
|
|
</Section>
|
|
) : null}
|
|
|
|
<Section title="Available targets">
|
|
<div className="card-grid">
|
|
{releaseManifest.platforms.map((platform) => {
|
|
const metadataItems = buildReleaseMetadataItems(platform)
|
|
return (
|
|
<article key={platform.platform_key} className="card">
|
|
<h3>{platform.platform}</h3>
|
|
<p className="status-pill">{platform.subtitle}</p>
|
|
<p>{platform.details}</p>
|
|
{metadataItems.length > 0 ? (
|
|
<ul className="list top-gap">
|
|
{metadataItems.map((item) => (
|
|
<li key={`${platform.platform_key}-${item.label}`}>
|
|
{item.label}: {item.value}
|
|
</li>
|
|
))}
|
|
</ul>
|
|
) : null}
|
|
<ReleaseValidationSummary platform={platform} />
|
|
{platform.configured ? (
|
|
<Link className="button button--primary button--full" to={buildProtectedDownloadPath(platform.platform_key)}>
|
|
Sign in for {platform.platform} access
|
|
</Link>
|
|
) : (
|
|
<div className="button button--ghost button--full is-disabled" aria-disabled="true">
|
|
Release URL not configured yet
|
|
</div>
|
|
)}
|
|
</article>
|
|
)
|
|
})}
|
|
</div>
|
|
</Section>
|
|
|
|
<Section title="How the release lane works">
|
|
<div className="card-grid">
|
|
{desktopDownloadSteps.map((step, index) => (
|
|
<article key={step} className="card card--compact">
|
|
<p className="status-pill">{index + 1}</p>
|
|
<p>{step}</p>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<SimulatorManualSection
|
|
title="What the installed runtime already owns"
|
|
description="Download posture is stronger when the page also explains the real software lane operators receive after the package handoff."
|
|
/>
|
|
|
|
<HigherDimensionalRuntimeGuideSection
|
|
title="Higher-dimensional family guide"
|
|
description="This keeps the download lane concrete about which serious family runtimes are already real and what host posture each one currently uses."
|
|
/>
|
|
|
|
<BulletCardSection
|
|
title="Current input and runtime control truth"
|
|
description="The download lane should also teach the real control boundary before the first session starts, including what is strong now and what still remains gated."
|
|
cards={[...inputAndDevicePostureCards, ...runtimeControlGuideCards]}
|
|
/>
|
|
|
|
<BrowserDesktopRealitySection />
|
|
|
|
<SurfaceChoiceGuideSection description="Download posture is clearer when the current best surface is explicit: public for target and release context, protected for entitlement, and desktop for the real training runtime." />
|
|
|
|
<PublicReleaseDecisionGuideSection
|
|
releaseManifest={releaseManifest}
|
|
description="The download page should also say whether the next honest move is protected desktop access, pricing/provisioning, browser/account continuity, or notices/source follow-through."
|
|
/>
|
|
|
|
<BrowserAuthMethodsSection
|
|
description="Download posture is clearer when the current shared-auth sign-in lineup is visible before operators cross into the protected entitlement and package-delivery lane."
|
|
/>
|
|
|
|
<BulletCardSection
|
|
title="First launch and desktop setup"
|
|
description="This keeps the download page useful after the archive is in hand: what to verify, how to pair the app, and which current runtime lanes matter first."
|
|
cards={desktopFirstLaunchCards}
|
|
/>
|
|
|
|
<DownloadableOperatorManualSection
|
|
description="The download lane now also includes a same-origin offline manual so the first-session path, current controls, higher-dimensional runtime guide, and rollout boundary can be carried alongside the desktop build."
|
|
/>
|
|
|
|
<OperatorDesktopQuickstartSection title="First desktop session after install" />
|
|
|
|
<Section title="Release posture">
|
|
<PublicLaunchStatus title="Desktop release access stays launch-honest" />
|
|
</Section>
|
|
|
|
<PublicPackagedDesktopProofSection
|
|
platform={windowsValidationPlatform}
|
|
actions={[
|
|
{ to: '/changelog', label: 'Review release notes' },
|
|
{ to: '/open-source-notices', label: 'Review notices' },
|
|
]}
|
|
/>
|
|
|
|
<BulletCardSection
|
|
title="Digital delivery workflow"
|
|
description="The download page should explain the real delivery sequence from platform selection to protected entitlement and first desktop launch."
|
|
cards={digitalDeliveryCards}
|
|
/>
|
|
|
|
<Section
|
|
title="Browser and desktop responsibilities"
|
|
description="The release lane is easier to trust when the site explains why some actions stay public, some stay protected, and the simulator itself stays native."
|
|
>
|
|
<DeliverySurfaceResponsibilitiesGrid />
|
|
</Section>
|
|
|
|
<BulletCardSection
|
|
title="Distribution doctrine"
|
|
description="Download posture should stay tied to package proof, notices, and the desktop-first simulator boundary."
|
|
cards={distributionDoctrineCards}
|
|
/>
|
|
|
|
<Section title="Release integrity and documentation">
|
|
<div className="card-grid">
|
|
{desktopReleaseSignals.map((signal) => (
|
|
<article key={signal.title} className="card">
|
|
<h3>{signal.title}</h3>
|
|
<p>{signal.description}</p>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<ReleaseAuthorityBundleSection
|
|
releaseManifest={releaseManifest}
|
|
description="Download posture is more trustworthy when docs, release notes, corresponding source, notices repository, and operator escalation remain visible as one coherent release bundle."
|
|
/>
|
|
|
|
<Section title="Why this page does not expose raw download URLs">
|
|
<article className="callout">
|
|
<p>
|
|
HyperTwist treats desktop distribution as an account-gated release surface.
|
|
Public pages can describe supported targets and release posture, but the actual
|
|
download links live behind the protected dashboard where plan and entitlement
|
|
state are resolved.
|
|
</p>
|
|
<Link className="button button--ghost" to={buildProtectedDownloadPath('windows')}>
|
|
Open protected download lane
|
|
</Link>
|
|
</article>
|
|
</Section>
|
|
|
|
<Section title="Pair the desktop app with your browser account">
|
|
<article className="callout">
|
|
<p>
|
|
After sign-in, open the operator dashboard to generate a desktop-link token.
|
|
That token is designed to hand browser identity and plan posture over to the local desktop app without exposing your password.
|
|
</p>
|
|
<Link className="button button--ghost" to={buildLoginPath('/app')}>
|
|
Open protected dashboard
|
|
</Link>
|
|
</article>
|
|
</Section>
|
|
</MarketingShell>
|
|
</>
|
|
)
|
|
}
|
|
|
|
export function OpenSourceNoticesPage() {
|
|
const { releaseManifest, windowsValidationPlatform } = usePublicReleaseManifestView(
|
|
'public-open-source-notices',
|
|
)
|
|
|
|
return (
|
|
<>
|
|
<SiteMetadata
|
|
title="HyperTwist open-source notices"
|
|
description="Review HyperTwist public open-source notices and corresponding-source guidance for downloadable distribution surfaces."
|
|
canonicalPath="/open-source-notices"
|
|
/>
|
|
<MarketingShell
|
|
eyebrow="Legal and notices"
|
|
title="Open-source notices for public distribution surfaces."
|
|
lede="HyperTwist pricing, checkout, release, and download pages must make legal and corresponding-source guidance visible whenever shipped builds include MPL-covered material."
|
|
>
|
|
<Section title="Key components">
|
|
<div className="card-grid">
|
|
{openSourceNotices.map((item) => (
|
|
<article className="card" key={item.component}>
|
|
<h3>{item.component}</h3>
|
|
<p className="status-pill">{item.license}</p>
|
|
<p>{item.whyItMatters}</p>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<Section title="Corresponding source">
|
|
<div className="card">
|
|
<p>
|
|
MPL-covered shipped builds need a stable corresponding-source location for the exact distributed material.
|
|
</p>
|
|
<ul className="list">
|
|
<li>
|
|
Public corresponding-source URL:{' '}
|
|
{releaseManifest.corresponding_source_url ? (
|
|
<a href={releaseManifest.corresponding_source_url} target="_blank" rel="noreferrer">{releaseManifest.corresponding_source_url}</a>
|
|
) : (
|
|
'configure the public corresponding-source URL before external launch'
|
|
)}
|
|
</li>
|
|
<li>
|
|
Public repository / notices reference:{' '}
|
|
{releaseManifest.open_source_repo_url ? (
|
|
<a href={releaseManifest.open_source_repo_url} target="_blank" rel="noreferrer">{releaseManifest.open_source_repo_url}</a>
|
|
) : (
|
|
'configure the public repository/notices URL before external launch'
|
|
)}
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
Official MPL 2.0 license text:{' '}
|
|
<a href="https://www.mozilla.org/en-US/MPL/2.0/" target="_blank" rel="noreferrer">
|
|
https://www.mozilla.org/en-US/MPL/2.0/
|
|
</a>
|
|
</p>
|
|
</div>
|
|
</Section>
|
|
|
|
<ReleaseAuthorityBundleSection
|
|
releaseManifest={releaseManifest}
|
|
title="Release and source references"
|
|
description="The notices lane is stronger when corresponding source, release notes, docs, repo/notices references, and operator escalation stay visible together instead of being scattered across separate public pages."
|
|
/>
|
|
|
|
<Section title="Distribution readiness">
|
|
<PublicLaunchStatus title="Notices and corresponding-source readiness" />
|
|
</Section>
|
|
|
|
<SurfaceChoiceGuideSection description="Legal pages are more useful when they still tell the operator where to go next: public for release-safe notice context, protected for account-aware release work, and desktop for the actual shipped build." />
|
|
|
|
<PublicReleaseDecisionGuideSection
|
|
releaseManifest={releaseManifest}
|
|
description="The notices lane should also say plainly whether the next honest move is protected desktop access, pricing/provisioning, browser/account continuity, or notices/source follow-through."
|
|
/>
|
|
|
|
<BrowserDesktopRealitySection
|
|
title="Why notices stay in the browser shell while execution stays native"
|
|
description="Legal and corresponding-source follow-through belong to the public/protected browser surfaces even when the actual simulator remains a desktop-first runtime."
|
|
/>
|
|
|
|
<Section
|
|
title="Current surface authority map"
|
|
description="Distribution and corresponding-source language stays safer when the live public, protected, embedded-browser, and native simulator boundaries remain explicit."
|
|
>
|
|
<ProductSurfaceMatrix rows={productSurfaceMatrixRows} />
|
|
</Section>
|
|
|
|
<PublicPackagedDesktopProofSection
|
|
platform={windowsValidationPlatform}
|
|
actions={[
|
|
{ to: '/download', label: 'Open download center' },
|
|
{ to: '/changelog', label: 'Review release notes' },
|
|
]}
|
|
/>
|
|
|
|
<Section
|
|
title="Distribution doctrine"
|
|
description="These public legal surfaces should explain why the website is part of the release story without pretending it has replaced the native simulator."
|
|
>
|
|
<div className="card-grid">
|
|
{distributionDoctrineCards.map((card) => (
|
|
<article className="card" key={card.title}>
|
|
<h3>{card.title}</h3>
|
|
<p>{card.description}</p>
|
|
<ul className="list top-gap">
|
|
{card.bullets.map((bullet) => (
|
|
<li key={bullet}>{bullet}</li>
|
|
))}
|
|
</ul>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<Section
|
|
title="Release and redistribution checklist"
|
|
description="Legal pages stay more useful when they explain the concrete release follow-through that should happen before broader redistribution."
|
|
>
|
|
<div className="card-grid">
|
|
{releaseRolloutChecklist.map((card) => (
|
|
<article className="card" key={card.title}>
|
|
<h3>{card.title}</h3>
|
|
<ul className="list top-gap">
|
|
{card.bullets.map((bullet) => (
|
|
<li key={bullet}>{bullet}</li>
|
|
))}
|
|
</ul>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<PublicManualRouteAtlasSection
|
|
title="Which public route should you open next?"
|
|
description="The notices lane is part of the same operator manual family as the rest of the public site, so it should keep the strongest adjacent public routes visible instead of acting like an isolated compliance stub."
|
|
limit={6}
|
|
/>
|
|
|
|
<DownloadableOperatorManualSection
|
|
description="The legal/distribution lane now also keeps the offline operator manual reachable so corresponding-source, rollout, download, and native-runtime boundary guidance can travel together."
|
|
/>
|
|
</MarketingShell>
|
|
</>
|
|
)
|
|
}
|
|
|
|
export function PrivacyPage() {
|
|
const { releaseManifest, windowsValidationPlatform } = usePublicReleaseManifestView('public-privacy')
|
|
|
|
return (
|
|
<>
|
|
<SiteMetadata
|
|
title="HyperTwist privacy"
|
|
description="Understand the HyperTwist privacy posture for browser account access, desktop-link issuance, and the desktop-first simulator boundary."
|
|
canonicalPath="/privacy"
|
|
/>
|
|
<MarketingShell
|
|
eyebrow="Privacy"
|
|
title="Privacy posture"
|
|
lede="HyperTwist keeps the browser shell narrow and the simulator desktop-first. Privacy descriptions must reflect that separation clearly."
|
|
>
|
|
<Section title="Core points">
|
|
<article className="card">
|
|
<ul className="list">
|
|
<li>The public website stores account/session data needed for authentication, plan access, and desktop-link issuance.</li>
|
|
<li>The browser shell does not claim ownership over the full simulator runtime state unless a future browser-client packet is explicitly opened.</li>
|
|
<li>Support, billing, and release operations should collect only the data required to deliver digital access and maintain legal compliance.</li>
|
|
</ul>
|
|
</article>
|
|
</Section>
|
|
|
|
<Section
|
|
title="Practical privacy boundary"
|
|
description="Privacy wording should follow the actual product split instead of flattening the browser shell and native simulator into one vague surface."
|
|
>
|
|
<div className="card-grid">
|
|
{privacyBoundaryCards.map((card) => (
|
|
<article key={card.title} className="card">
|
|
<h3>{card.title}</h3>
|
|
<p>{card.description}</p>
|
|
<ul className="list top-gap">
|
|
{card.bullets.map((bullet) => (
|
|
<li key={bullet}>{bullet}</li>
|
|
))}
|
|
</ul>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<SurfaceChoiceGuideSection description="Privacy posture is clearer when the next working surface is explicit too: public for policy context, protected for identity and account work, and desktop for simulator execution." />
|
|
|
|
<PublicReleaseDecisionGuideSection
|
|
releaseManifest={releaseManifest}
|
|
description="Privacy posture is stronger when it also says whether the next honest move is protected desktop access, pricing/provisioning, browser/account continuity, or notices/source follow-through."
|
|
/>
|
|
|
|
<Section
|
|
title="Browser and desktop responsibilities"
|
|
description="Privacy language stays honest when it says plainly which surface owns public identity work and which surface owns simulator execution."
|
|
>
|
|
<DeliverySurfaceResponsibilitiesGrid limit={3} />
|
|
</Section>
|
|
|
|
<Section
|
|
title="Current surface authority map"
|
|
description="This keeps privacy expectations grounded in the live product topology instead of a vague all-in-one app claim."
|
|
>
|
|
<ProductSurfaceMatrix rows={productSurfaceMatrixRows} />
|
|
</Section>
|
|
|
|
<PublicPackagedDesktopProofSection
|
|
platform={windowsValidationPlatform}
|
|
actions={[
|
|
{ to: '/download', label: 'Open download center' },
|
|
{ to: '/support', label: 'Open support' },
|
|
]}
|
|
/>
|
|
|
|
<ReleaseAuthorityBundleSection
|
|
releaseManifest={releaseManifest}
|
|
description="Privacy posture remains more actionable when docs, release notes, corresponding source, notices repository, and operator support stay reachable from the same public boundary page."
|
|
/>
|
|
|
|
<Section
|
|
title="Support-safe escalation boundary"
|
|
description="When privacy or access concerns show up during rollout, support should keep account, runtime, and compliance questions separated instead of flattening them together."
|
|
>
|
|
<div className="card-grid">
|
|
{supportEscalationCards.map((card) => (
|
|
<article key={card.title} className="card">
|
|
<h3>{card.title}</h3>
|
|
<p>{card.description}</p>
|
|
<ul className="list top-gap">
|
|
{card.bullets.map((bullet) => (
|
|
<li key={bullet}>{bullet}</li>
|
|
))}
|
|
</ul>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
</MarketingShell>
|
|
</>
|
|
)
|
|
}
|
|
|
|
export function TermsPage() {
|
|
const { releaseManifest, windowsValidationPlatform } = usePublicReleaseManifestView('public-terms')
|
|
|
|
return (
|
|
<>
|
|
<SiteMetadata
|
|
title="HyperTwist terms"
|
|
description="Review the HyperTwist terms of access for browser account routes, desktop delivery, and open-source notice obligations."
|
|
canonicalPath="/terms"
|
|
/>
|
|
<MarketingShell
|
|
eyebrow="Terms"
|
|
title="Terms of access"
|
|
lede="HyperTwist access is digital-first and plan-gated. Terms should match the actual delivery and account model."
|
|
>
|
|
<Section title="Service posture">
|
|
<article className="card">
|
|
<ul className="list">
|
|
<li>Browser access covers public pages, account, release, download, and operator/dashboard surfaces.</li>
|
|
<li>The simulator itself is delivered through the desktop lane unless a later browser-client branch is explicitly opened.</li>
|
|
<li>Downloaded builds and their public distribution pages remain subject to open-source notice and corresponding-source disclosure rules where applicable.</li>
|
|
</ul>
|
|
</article>
|
|
</Section>
|
|
|
|
<Section
|
|
title="Terms in practice"
|
|
description="These terms-oriented boundaries keep the public site, protected dashboard, and desktop simulator aligned with the actual delivery model."
|
|
>
|
|
<div className="card-grid">
|
|
{termsBoundaryCards.map((card) => (
|
|
<article key={card.title} className="card">
|
|
<h3>{card.title}</h3>
|
|
<p>{card.description}</p>
|
|
<ul className="list top-gap">
|
|
{card.bullets.map((bullet) => (
|
|
<li key={bullet}>{bullet}</li>
|
|
))}
|
|
</ul>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<SurfaceChoiceGuideSection description="Terms are stronger when they point to the right live surface as well: public for access/legal context, protected for entitled release work, and desktop for the simulator itself." />
|
|
|
|
<PublicReleaseDecisionGuideSection
|
|
releaseManifest={releaseManifest}
|
|
description="The terms lane should also make the next honest operator move explicit: protected desktop access, pricing/provisioning, browser/account continuity, or notices/source follow-through."
|
|
/>
|
|
|
|
<Section
|
|
title="Browser and desktop responsibilities"
|
|
description="Terms stay more accurate when they keep public site duties, protected dashboard duties, and native simulator duties separated."
|
|
>
|
|
<DeliverySurfaceResponsibilitiesGrid />
|
|
</Section>
|
|
|
|
<Section
|
|
title="Current surface authority map"
|
|
description="This is the quickest way to see which live surface owns access, execution, and future-gated branches today."
|
|
>
|
|
<ProductSurfaceMatrix rows={productSurfaceMatrixRows} />
|
|
</Section>
|
|
|
|
<PublicPackagedDesktopProofSection
|
|
platform={windowsValidationPlatform}
|
|
actions={[
|
|
{ to: '/download', label: 'Open download center' },
|
|
{ to: '/open-source-notices', label: 'Review notices' },
|
|
]}
|
|
/>
|
|
|
|
<ReleaseAuthorityBundleSection
|
|
releaseManifest={releaseManifest}
|
|
description="Terms and access language are easier to trust when they keep public docs, release notes, corresponding source, notices references, and support follow-through in one visible release bundle."
|
|
/>
|
|
|
|
<Section
|
|
title="Release and redistribution checklist"
|
|
description="Terms become materially more trustworthy when they stay attached to release proof, download gating, and legal follow-through."
|
|
>
|
|
<div className="card-grid">
|
|
{releaseRolloutChecklist.map((card) => (
|
|
<article key={card.title} className="card">
|
|
<h3>{card.title}</h3>
|
|
<ul className="list top-gap">
|
|
{card.bullets.map((bullet) => (
|
|
<li key={bullet}>{bullet}</li>
|
|
))}
|
|
</ul>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
</MarketingShell>
|
|
</>
|
|
)
|
|
}
|
|
|
|
export function ShippingPaymentPage() {
|
|
const { releaseManifest, windowsValidationPlatform } = usePublicReleaseManifestView('public-shipping-payment')
|
|
|
|
return (
|
|
<>
|
|
<SiteMetadata
|
|
title="HyperTwist shipping and payment"
|
|
description="HyperTwist is delivered digitally through account access, release pages, and desktop downloads with Paddle-ready billing posture."
|
|
canonicalPath="/shipping-payment"
|
|
/>
|
|
<MarketingShell
|
|
eyebrow="Shipping & payment"
|
|
title="Digital delivery only"
|
|
lede="HyperTwist is not a physical-goods storefront. Delivery happens through authenticated account access, release pages, and desktop downloads."
|
|
>
|
|
<Section title="Delivery model">
|
|
<article className="card">
|
|
<p>{paddleReadyDescription}</p>
|
|
<ul className="list">
|
|
<li>No physical goods ship through this site.</li>
|
|
<li>Pricing and checkout are structured for Paddle-backed digital plans.</li>
|
|
<li>Desktop downloads must remain paired with public notices and legal links when required by shipped-code obligations.</li>
|
|
</ul>
|
|
</article>
|
|
</Section>
|
|
|
|
<Section
|
|
title="Digital delivery workflow"
|
|
description="A professional digital-delivery lane does more than expose a buy button. It keeps release posture, entitlement, and the desktop handoff coherent."
|
|
>
|
|
<div className="card-grid">
|
|
{digitalDeliveryCards.map((card) => (
|
|
<article key={card.title} className="card">
|
|
<h3>{card.title}</h3>
|
|
<p>{card.description}</p>
|
|
<ul className="list top-gap">
|
|
{card.bullets.map((bullet) => (
|
|
<li key={bullet}>{bullet}</li>
|
|
))}
|
|
</ul>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<Section
|
|
title="What happens after access is granted"
|
|
description="Payment surfaces are stronger when they explain the next real operator steps instead of stopping at checkout language."
|
|
>
|
|
<div className="card-grid">
|
|
{operatorManualTracks.slice(1, 4).map((track) => (
|
|
<article key={track.title} className="card">
|
|
<h3>{track.title}</h3>
|
|
<p>{track.description}</p>
|
|
<ul className="list top-gap">
|
|
{track.steps.map((step) => (
|
|
<li key={step}>{step}</li>
|
|
))}
|
|
</ul>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<SurfaceChoiceGuideSection description="Shipping and payment posture stays practical when the next live surface is explicit instead of implied." />
|
|
|
|
<PublicReleaseDecisionGuideSection
|
|
releaseManifest={releaseManifest}
|
|
description="Shipping and payment posture is clearer when it also says whether the next honest move is protected desktop access, pricing/provisioning, browser/account continuity, or notices/source follow-through."
|
|
/>
|
|
|
|
<BrowserAuthMethodsSection
|
|
description="Payment and entitlement language is easier to trust when the current shared-auth sign-in lineup stays visible before protected release access and desktop provisioning."
|
|
/>
|
|
|
|
<BrowserDesktopRealitySection
|
|
title="Why checkout and entitlement stay on the web while training stays native"
|
|
description="The commercial/browser shell owns access, billing, and release posture so the packaged simulator can remain focused on execution quality instead of becoming a confused storefront."
|
|
/>
|
|
|
|
<Section
|
|
title="Browser and desktop responsibilities"
|
|
description="Shipping and payment surfaces should explain why checkout, entitlement, and release posture stay on the web while simulator execution stays native."
|
|
>
|
|
<DeliverySurfaceResponsibilitiesGrid />
|
|
</Section>
|
|
|
|
<Section
|
|
title="Current surface authority map"
|
|
description="Digital-delivery pages stay stronger when the live public, protected, embedded-browser, and native simulator responsibilities are visible in one place."
|
|
>
|
|
<ProductSurfaceMatrix rows={productSurfaceMatrixRows} />
|
|
</Section>
|
|
|
|
<PublicPackagedDesktopProofSection
|
|
platform={windowsValidationPlatform}
|
|
actions={[
|
|
{ to: '/download', label: 'Open download center' },
|
|
{ to: '/open-source-notices', label: 'Review notices' },
|
|
]}
|
|
/>
|
|
|
|
<ReleaseAuthorityBundleSection
|
|
releaseManifest={releaseManifest}
|
|
description="Shipping and payment posture should carry the same docs, release, source, notices, and support bundle as the rest of the public desktop-distribution lane."
|
|
/>
|
|
|
|
<Section
|
|
title="Terms of access in practice"
|
|
description="The shipping/payment page should still tell operators what they are actually buying access to and what remains outside the current browser scope."
|
|
>
|
|
<div className="card-grid">
|
|
{termsBoundaryCards.map((card) => (
|
|
<article key={card.title} className="card">
|
|
<h3>{card.title}</h3>
|
|
<p>{card.description}</p>
|
|
<ul className="list top-gap">
|
|
{card.bullets.map((bullet) => (
|
|
<li key={bullet}>{bullet}</li>
|
|
))}
|
|
</ul>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<Section
|
|
title="Distribution doctrine"
|
|
description="This keeps shipping/payment language attached to package proof, notices, and the desktop-first runtime truth."
|
|
>
|
|
<div className="card-grid">
|
|
{distributionDoctrineCards.map((card) => (
|
|
<article key={card.title} className="card">
|
|
<h3>{card.title}</h3>
|
|
<p>{card.description}</p>
|
|
<ul className="list top-gap">
|
|
{card.bullets.map((bullet) => (
|
|
<li key={bullet}>{bullet}</li>
|
|
))}
|
|
</ul>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<Section
|
|
title="Release and redistribution checklist"
|
|
description="Digital delivery is only complete when payment, download, proof, and legal follow-through stay aligned."
|
|
>
|
|
<div className="card-grid">
|
|
{releaseRolloutChecklist.map((card) => (
|
|
<article key={card.title} className="card">
|
|
<h3>{card.title}</h3>
|
|
<ul className="list top-gap">
|
|
{card.bullets.map((bullet) => (
|
|
<li key={bullet}>{bullet}</li>
|
|
))}
|
|
</ul>
|
|
</article>
|
|
))}
|
|
</div>
|
|
</Section>
|
|
|
|
<PublicManualRouteAtlasSection
|
|
title="Which public route should you open next?"
|
|
description="The shipping/payment lane now also keeps the strongest adjacent manual routes visible so checkout, launch posture, release notes, notices, and simulator onboarding remain one coherent product story."
|
|
limit={6}
|
|
/>
|
|
|
|
<DownloadableOperatorManualSection
|
|
description="The delivery lane also keeps the offline operator manual attached so first-session setup, rollout posture, higher-dimensional runtime guidance, and browser-versus-desktop truth can accompany the purchase and download path."
|
|
/>
|
|
</MarketingShell>
|
|
</>
|
|
)
|
|
}
|