@sylphx/flow 2.8.0 → 2.10.0

package/assets/slash-commands/saas-admin.md

@@ -1,123 +0,0 @@
----
-name: saas-admin
-description: SaaS admin platform review - RBAC, bootstrap, config, feature flags, ops
-agent: coder
----
-
-# Admin Platform Review
-
-## Scope
-
-Review admin systems: RBAC, bootstrap flow, configuration management, feature flags governance, operational tooling, and impersonation.
-
-## Specification
-
-### Access Control (RBAC)
-
-* **Least privilege principle**: Users get minimum permissions needed.
-* Role hierarchy with clear inheritance.
-* Permission granularity (resource-level, action-level).
-* All authorization is **server-enforced**; no client-trust.
-* Role changes require appropriate privilege level and are audited.
-
-### Admin Bootstrap (Hard Requirement)
-
-* Admin bootstrap must **not rely on file seeding**.
-* Use a secure, auditable **first-login allowlist** for the initial SUPER_ADMIN.
-* **Permanently disable bootstrap** after completion — no re-entry.
-* All privilege grants must be server-enforced and recorded in the audit log.
-* The allowlist must be managed via **secure configuration (environment/secret store)**, not code or DB seeding.
-
-### Configuration Management
-
-* All **non-secret** product-level configuration must be manageable via admin (server-enforced).
-* Configuration changes require **validation and change history**.
-* Secrets/credentials are **environment-managed only**; admin may expose safe readiness/health visibility, not raw secrets.
-* Support for environment-specific overrides (dev/staging/prod).
-* Rollback capability for configuration changes.
-
-### Feature Flags Governance
-
-* Gradual rollout support (percentage-based, user segment-based).
-* A/B testing integration where applicable.
-* **Audit trail** for all flag changes (who/when/why).
-* Emergency **kill switches** for rapid disable.
-* Flag lifecycle management (created → active → deprecated → removed).
-* Server-enforced evaluation; no client-side flag source-of-truth.
-
-### Operational Management
-
-* **User/account management tools**:
-  * Search, view, edit user profiles
-  * Account status management (active, suspended, banned)
-  * Manual verification/unverification
-
-* **Entitlements/access management**:
-  * View and modify user entitlements
-  * Grant/revoke access with audit trail
-  * Bulk operations with safeguards
-
-* **Lifecycle actions**:
-  * Account suspension/reactivation
-  * Data export (for user requests)
-  * Account deletion with proper cascade
-
-* **Issue resolution workflows**:
-  * Support ticket integration
-  * Action history per user
-  * Notes and annotations
-
-* **Step-up controls** for sensitive actions:
-  * Actions affecting money/credits require MFA
-  * Actions affecting security posture require MFA
-  * Destructive actions require confirmation + reason
-
-### Impersonation
-
-* Impersonation allowed **with explicit safeguards**:
-  * Requires elevated privilege level
-  * Time-limited sessions (auto-expire)
-  * Full audit logging (start, actions, end)
-  * Clear indicator in UI during impersonation
-  * Cannot impersonate higher-privilege users
-* All actions during impersonation attributed to both impersonator and target.
-* Optional: Visible indicator to impersonated user that session was accessed.
-
-### Admin Audit Logging
-
-* **All admin actions must be auditable**:
-  * Who performed the action
-  * When (timestamp with timezone)
-  * What action was taken
-  * Why (required reason for sensitive actions)
-  * Before/after state for mutations
-  * Correlation to session/request
-* Audit logs must be:
-  * Immutable (append-only)
-  * Queryable and filterable
-  * Exportable for compliance
-  * Retained per data retention policy
-
-## Domain Discovery
-
-After reviewing compliance with spec, explore improvements:
-
-* **Admin UX**: Is the admin panel efficient for common tasks? Keyboard shortcuts? Bulk actions?
-* **Self-service vs admin**: What admin actions could be self-service for users?
-* **Automation**: What repetitive admin tasks could be automated? Scheduled jobs?
-* **Alerting**: Should certain admin actions trigger alerts? (e.g., mass deletions)
-* **Delegation**: Can some admin tasks be delegated to lower roles safely?
-* **Mobile admin**: Is there a need for mobile admin access? How to secure?
-
-## Domain Gates
-
-* [ ] RBAC implemented with least privilege
-* [ ] Bootstrap flow is secure and one-time only
-* [ ] Config changes are validated and audited
-* [ ] Feature flags have full audit trail
-* [ ] Sensitive actions require step-up (MFA)
-* [ ] Impersonation is time-limited and fully logged
-* [ ] All admin actions are auditable
-* [ ] Audit logs are immutable and queryable
-* [ ] No hardcoded admin credentials anywhere
-* [ ] Admin endpoints are rate-limited

package/assets/slash-commands/saas-auth.md

@@ -1,78 +0,0 @@
----
-name: saas-auth
-description: SaaS identity review - SSO, passkeys, verification, account security
-agent: coder
----
-
-# Identity & Account Security Review
-
-## Scope
-
-Review identity systems: authentication methods, SSO providers, passkeys/WebAuthn, verification flows, session management, and account security surfaces.
-
-## Specification
-
-### Identity Providers (SSO)
-
-* SSO providers (minimum): **Google, Apple, Facebook, Microsoft, GitHub** (prioritize by audience).
-* If provider env/secrets are missing, **hide** the login option (no broken/disabled UI).
-* Allow linking multiple providers and safe unlinking; server-enforced and abuse-protected.
-
-### Passkeys (WebAuthn)
-
-* Passkeys are first-class with secure enrollment/usage/recovery.
-* Must support cross-device authentication where platform allows.
-
-### Verification
-
-* **Email verification is mandatory** baseline for high-impact capabilities.
-* **Phone verification is optional** and used as risk-based step-up (anti-abuse, higher-trust flows, recovery); consent-aware and data-minimizing.
-
-### Membership and Entitlements
-
-* Membership is entitlement-driven and server-enforced.
-* All authorization/entitlements are **server-enforced**; no client-trust.
-
-### Account Security Surface
-
-* Provide a dedicated **Account Security** surface.
-* **Minimum acceptance criteria**:
-  * Session/device visibility and revocation
-  * MFA/passkey management
-  * Linked identity provider management
-  * Key security event visibility (and export where applicable)
-* All server-enforced and auditable.
-
-### Session Management
-
-* Session/device visibility + revocation available to user.
-* Security event visibility with clear audit trail.
-* Recovery governance (including support-assisted recovery) with strict audit logging.
-* Step-up authentication for sensitive actions.
-
-### Password Security
-
-* Password UX: masked + temporary reveal option.
-* No plaintext passwords in logs/returns/storage/telemetry.
-* MFA required for Admin/SUPER_ADMIN; step-up for high-risk actions.
-
-## Domain Discovery
-
-After reviewing compliance with spec, explore improvements:
-
-* **Onboarding friction**: Is sign-up flow optimized? Too many steps? Missing social providers for target market?
-* **Security vs UX balance**: Are step-up challenges appropriate? Too frequent? Too rare?
-* **Recovery flows**: Is account recovery secure yet accessible? Support burden from lockouts?
-* **Modern auth**: Are passkeys properly promoted? Is passwordless an option?
-* **Trust signals**: Are verified badges shown? Does verification unlock features appropriately?
-
-## Domain Gates
-
-* [ ] All SSO providers working (or hidden if unconfigured)
-* [ ] Passkey enrollment/usage/recovery tested
-* [ ] Email verification enforced for high-impact actions
-* [ ] Account security surface complete (sessions, MFA, providers, events)
-* [ ] Session revocation works correctly
-* [ ] No client-trust for authorization decisions
-* [ ] Step-up auth for sensitive actions
-* [ ] No plaintext passwords anywhere

package/assets/slash-commands/saas-billing.md

@@ -1,68 +0,0 @@
----
-name: saas-billing
-description: SaaS billing review - Stripe, webhooks, pricing governance, ledger
-agent: coder
----
-
-# Billing & Payments Review
-
-## Scope
-
-Review all payment and billing systems: Stripe integration, webhook handling, pricing governance, subscription state machine, and financial-grade ledger (if applicable).
-
-## Specification
-
-### Billing State Machine (Hard Requirement)
-
-* **Billing and access state machine is mandatory**: define and validate the mapping **Stripe state → internal subscription state → entitlements**, including trial, past_due, unpaid, canceled, refund, and dispute outcomes.
-* UI must only present interpretable, non-ambiguous states derived from server-truth.
-* **No dual-write (hard requirement)**: subscription/payment truth must be derived from Stripe-driven events; internal systems must not directly rewrite billing truth or authorize entitlements based on non-Stripe truth, except for explicitly defined admin remediation flows that are fully server-enforced and fully audited.
-
-### Stripe Integration
-
-* Support subscriptions and one-time payments as product needs require.
-* Tax/invoicing and refund/dispute handling must be behaviorally consistent with product UX and entitlement state.
-
-### Webhook Handling (Hard Requirement)
-
-* Webhooks must be idempotent, retry-safe, out-of-order safe, auditable; billing UI reflects server-truth state without ambiguity.
-* **Webhook trust is mandatory (high-risk)**: webhook origin must be verified (signature verification and replay resistance). The Stripe **event id** must be used as the idempotency and audit correlation key; unverifiable events must be rejected and must trigger alerting.
-* **Out-of-order behavior must be explicit**: all webhook handlers must define and enforce a clear out-of-order strategy (event ordering is not guaranteed even for the same subscription), and must define final-state decision rules.
-
-### Pricing Governance (Stripe-first, not Dashboard-first)
-
-* Stripe is the system-of-record for products, prices, subscriptions, invoices, and disputes; internal systems must not contradict Stripe truth.
-* Pricing changes must be performed by creating new Stripe Prices and updating the "active sellable price" policy; historical prices must remain immutable for existing subscriptions unless an approved migration is executed.
-* Default pricing change policy is **grandfathering**: existing subscribers keep their current price; new customers use the currently active sellable price.
-* An operational-grade **Pricing Admin** must exist to manage creation of new Stripe Prices, activation/deactivation of sellable prices, and (optionally) controlled bulk subscription migrations; all actions must be governed by RBAC, step-up controls, and audit logs.
-* Stripe Dashboard is treated as monitoring/emergency access; non-admin Stripe changes must be detectable (drift), alertable, and remediable.
-
-### Financial-Grade Balance System (Only if "balance/credits/wallet" exists)
-
-* Any balance concept must be implemented as an **immutable ledger** (append-only source of truth), not a mutable balance field.
-* Deterministic precision (no floats), idempotent posting, concurrency safety, transactional integrity, and auditability are required.
-* Monetary flows must be currency-based and reconcilable with Stripe; credits (if used) must be governed as non-cash entitlements.
-
-### Auditability
-
-* **Auditability chain is mandatory** for any high-value mutation: who/when/why, before/after state, and correlation to the triggering request/job/webhook must be recorded and queryable.
-
-## Domain Discovery
-
-After reviewing compliance with spec, explore improvements:
-
-* **Conversion optimization**: Are there friction points in the checkout flow? Missing payment methods for target markets?
-* **Churn reduction**: Is dunning (failed payment retry) properly configured? Are there win-back opportunities?
-* **Pricing opportunities**: Are tiers properly differentiated? Is there usage-based pricing potential?
-* **Trial optimization**: Is trial-to-paid conversion measured and optimized?
-* **Upgrade/downgrade UX**: Is plan switching seamless? Prorated correctly?
-
-## Domain Gates
-
-* [ ] Stripe state machine fully mapped and documented
-* [ ] Webhook handlers are idempotent and out-of-order safe
-* [ ] Signature verification implemented and tested
-* [ ] Pricing admin exists with RBAC and audit
-* [ ] No dual-write violations
-* [ ] Ledger is append-only (if balance exists)
-* [ ] Billing UI reflects server-truth only

package/assets/slash-commands/saas-discovery.md

@@ -1,135 +0,0 @@
----
-name: saas-discovery
-description: SaaS strategic discovery - features, pricing, competitive research
-agent: coder
----
-
-# Strategic Discovery & Opportunities
-
-## Scope
-
-Cross-domain strategic exploration: identify new feature opportunities, optimize pricing/packaging, and conduct competitive research. This is NOT compliance checking — it's creative/strategic work to improve the product.
-
-## Mandate
-
-* **Exploration required**: identify improvements for competitiveness, completeness, usability, reliability, and monetization within fixed constraints.
-* Think beyond current implementation — what's missing? What would make users love this product?
-* Convert insights into **testable acceptance criteria**, not vague suggestions.
-
-## Feature Discovery
-
-### Process
-
-1. **Audit current capabilities**: What does the product do today?
-2. **Identify gaps**: What's missing that users expect?
-3. **Prioritize by impact**: What would move the needle most?
-4. **Define success criteria**: How would we know the feature works?
-
-### Areas to Explore
-
-* **User workflows**: Are there manual steps that could be automated?
-* **Integrations**: What third-party services should we connect to?
-* **Data/insights**: What data do we have that users would value seeing?
-* **Collaboration**: Are there multi-user/team features missing?
-* **Mobile**: Is the mobile experience feature-complete or degraded?
-* **API/Developer**: Should there be a public API? Webhooks for users?
-* **AI/Automation**: Where could AI add value without being gimmicky?
-
-### Output Format
-
-For each feature opportunity:
-```markdown
-**Feature**: [Name]
-**Problem**: [What user problem does this solve?]
-**Impact**: [High/Medium/Low] — [Why?]
-**Effort**: [High/Medium/Low] — [Why?]
-**Success Criteria**: [How do we measure success?]
-**Acceptance Criteria**:
-- [ ] [Specific, testable requirement]
-- [ ] [Another requirement]
-```
-
-## Pricing & Monetization Discovery
-
-### Process
-
-1. **Audit current pricing**: Tiers, features per tier, price points
-2. **Analyze value alignment**: Does pricing match perceived value?
-3. **Identify friction**: Where do users hesitate to pay?
-4. **Explore models**: Subscription, usage-based, hybrid, freemium
-
-### Areas to Explore
-
-* **Tier differentiation**: Are tiers clearly differentiated? Is there a "trapped middle"?
-* **Feature gating**: Are the right features gated? Too much in free? Too little?
-* **Price anchoring**: Is there a decoy tier? Is the recommended tier obvious?
-* **Trial optimization**: Is trial length optimal? What converts?
-* **Upgrade triggers**: What signals readiness to upgrade? Are we acting on them?
-* **Annual discounts**: Is annual pricing compelling enough?
-* **Add-ons**: Are there features that should be add-ons rather than tier-gated?
-* **Usage-based**: Would pay-per-use work for any features?
-
-### Output Format
-
-For each pricing opportunity:
-```markdown
-**Change**: [What to change]
-**Rationale**: [Why this improves monetization]
-**Expected Impact**: [Conversion? ARPU? Retention?]
-**Risk**: [What could go wrong?]
-**Test Plan**: [How to validate before full rollout]
-```
-
-## Competitive Research
-
-### Process
-
-1. **Identify competitors**: Direct and indirect (alternative solutions)
-2. **Analyze features**: What do they have that we don't?
-3. **Analyze pricing**: How do they package and price?
-4. **Analyze UX**: What do they do better? Worse?
-5. **Synthesize insights**: What should we adopt? Avoid? Differentiate on?
-
-### Areas to Explore
-
-* **Feature parity**: What table-stakes features are we missing?
-* **Differentiation**: What do we do uniquely well? How to amplify?
-* **Pricing position**: Are we premium, mid-market, or budget? Is that intentional?
-* **UX patterns**: What onboarding/guidance patterns work well elsewhere?
-* **Growth tactics**: How do competitors acquire and retain users?
-* **Market gaps**: What's everyone missing that we could own?
-
-### Output Format
-
-For each competitive insight:
-```markdown
-**Competitor**: [Name]
-**Observation**: [What we learned]
-**Implication**: [What this means for us]
-**Action**: [Specific recommendation]
-**Priority**: [High/Medium/Low]
-```
-
-## Synthesis
-
-After exploring all areas, produce a prioritized roadmap:
-
-### Immediate Wins (Do Now)
-High impact + Low effort opportunities
-
-### Strategic Investments (Plan Carefully)
-High impact + High effort opportunities
-
-### Quick Wins (When Available)
-Low impact + Low effort opportunities
-
-### Deprioritized (Defer/Skip)
-Low impact + High effort — document why not pursuing
-
-## Exit Criteria
-
-* [ ] Feature gaps identified with acceptance criteria
-* [ ] Pricing optimization opportunities documented
-* [ ] Competitive landscape analyzed
-* [ ] Prioritized roadmap produced
-* [ ] All recommendations have testable success criteria

package/assets/slash-commands/saas-growth.md

@@ -1,94 +0,0 @@
----
-name: saas-growth
-description: SaaS growth review - onboarding, referral, retention, guidance
-agent: coder
----
-
-# Growth Systems Review
-
-## Scope
-
-Review growth systems: onboarding flows, referral program, retention mechanics, viral/sharing features, and user guidance.
-
-## Specification
-
-### Growth System Foundation
-
-* The system must produce a coherent, measurable growth system for activation, sharing/virality, and retention, aligned with compliance and anti-abuse constraints.
-
-### Onboarding
-
-* Onboarding must be **outcome-oriented** (guide to first value, not just feature tour).
-* Localized for all supported locales.
-* Accessible (WCAG AA).
-* Instrumented (track completion, drop-off points).
-* Progressive disclosure — don't overwhelm new users.
-
-### Sharing/Virality
-
-* Sharing must be **consent-aware** (no spam, no dark patterns).
-* Abuse-resistant with rate limiting and detection.
-* Measurable end-to-end (share → click → signup → conversion).
-* Platform-appropriate sharing (native share sheet on mobile, copy link on desktop).
-
-### Retention
-
-* Retention must be **intentionally engineered**, not accidental.
-* Monitored with cohort analysis.
-* Protected against regressions (alert on retention drops).
-* Re-engagement flows (email, push) must be consent-governed.
-
-### Referral Program (Anti-Abuse Baseline Required)
-
-* Referral must be measurable, abuse-resistant, and governed:
-  * Clear attribution semantics (who referred whom, when)
-  * Reward lifecycle governance (pending → approved → paid, including revocation/clawbacks)
-  * Anti-fraud measures
-  * Admin reporting and audit capabilities
-  * Localized and instrumented
-
-* **Referral anti-fraud minimum baseline is mandatory**:
-  * Define minimum set of risk signals and enforcement measures
-  * Velocity controls (rate limiting referrals)
-  * Account/device linkage posture (detect self-referral)
-  * Risk-tiered enforcement (high-risk delays, low-risk instant)
-  * Reward delay/hold/freeze capabilities
-  * Clawback conditions clearly defined
-  * Auditable manual review/appeal posture where applicable
-
-### Support and Communications
-
-* Support/Contact surface must be discoverable, localized, WCAG AA, SEO-complete, privacy-safe, and auditable where relevant.
-* Newsletter subscription/preferences must be consent-aware; unsubscribe enforcement must be reliable and immediate.
-
-### Admin Platform (Growth-Related)
-
-* **Admin analytics and reporting are mandatory**:
-  * Comprehensive dashboards/reports for business, growth, billing, referral, support, and security/abuse signals
-  * Governed by RBAC
-  * Reporting must be consistent with system-of-record truth and auditable
-
-## Domain Discovery
-
-After reviewing compliance with spec, explore improvements:
-
-* **Activation optimization**: What's the "aha moment"? How fast do users reach it? What's blocking them?
-* **Viral loops**: Are there natural sharing moments? Can product usage generate invites?
-* **Retention hooks**: What brings users back? Email? Push? In-app value?
-* **Referral improvements**: Is the reward compelling? Is sharing frictionless? What's the k-factor?
-* **Churn analysis**: Why do users leave? Exit surveys? Behavioral patterns before churn?
-* **Expansion revenue**: Are there upsell opportunities? Usage-based triggers?
-
-## Domain Gates
-
-* [ ] Onboarding tracks completion and drop-off
-* [ ] Onboarding is localized and accessible
-* [ ] Sharing respects consent and has rate limits
-* [ ] Sharing is measurable end-to-end
-* [ ] Retention cohorts are tracked
-* [ ] Retention regression alerts exist
-* [ ] Referral attribution is accurate
-* [ ] Referral has anti-fraud controls
-* [ ] Reward lifecycle is auditable
-* [ ] Support surface is discoverable and localized
-* [ ] Newsletter unsubscribe works immediately

package/assets/slash-commands/saas-i18n.md

@@ -1,66 +0,0 @@
----
-name: saas-i18n
-description: SaaS internationalization review - locales, routing, canonicalization, hreflang
-agent: coder
----
-
-# Internationalization & Routing Review
-
-## Scope
-
-Review internationalization systems: locale support, URL routing strategy, canonicalization, hreflang implementation, and UGC handling across languages.
-
-## Specification
-
-### Supported Locales
-
-`en`, `zh-Hans`, `zh-Hant`, `es`, `ja`, `ko`, `de`, `fr`, `pt-BR`, `it`, `nl`, `pl`, `tr`, `id`, `th`, `vi`
-
-### URL Strategy: Prefix Except Default
-
-* English is default and **non-prefixed**.
-* `/en/*` must **not exist**; permanently redirect to non-prefixed equivalent.
-* All non-default locales are `/<locale>/...`.
-
-### Globalization Rules
-
-* Use Intl APIs for formatting (dates, numbers, currencies).
-* Explicit fallback rules for missing translations.
-* **Missing translation keys must fail build** — no silent fallbacks in production.
-* No hardcoded user-facing strings outside localization system.
-
-### UGC Canonicalization
-
-* Separate UI language from content language.
-* Exactly one canonical URL per UGC resource determined by content language.
-* No indexable locale-prefixed duplicates unless primary content is truly localized; otherwise redirect to canonical.
-* Canonical/hreflang/sitemap must reflect only true localized variants.
-
-### SEO Requirements
-
-* `hreflang` tags with `x-default` pointing to non-prefixed (English) version.
-* `sitemap.xml` containing only true localized variants.
-* Canonical URLs properly set per page.
-* No duplicate content across locale paths.
-
-## Domain Discovery
-
-After reviewing compliance with spec, explore improvements:
-
-* **Market expansion**: Are high-value markets missing? (e.g., Arabic RTL, Hindi)
-* **Translation quality**: Are translations professional or machine-generated? User complaints?
-* **Locale detection**: Is auto-detection helpful or annoying? Is manual switching easy?
-* **Regional pricing**: Does i18n support regional pricing display? Currency localization?
-* **Legal localization**: Are terms/privacy properly localized per jurisdiction?
-* **Date/time handling**: Timezone-aware displays? User preference respected?
-
-## Domain Gates
-
-* [ ] All supported locales have complete translations
-* [ ] `/en/*` returns 301 redirect to non-prefixed
-* [ ] Missing translation keys fail build
-* [ ] hreflang tags present and correct
-* [ ] x-default points to non-prefixed version
-* [ ] Sitemap contains only true localized pages
-* [ ] UGC has single canonical URL per content
-* [ ] No hardcoded strings in components

package/assets/slash-commands/saas-platform.md

@@ -1,87 +0,0 @@
----
-name: saas-platform
-description: SaaS frontend review - design system, SEO, PWA, performance, accessibility
-agent: coder
----
-
-# Frontend & Platform Review
-
-## Scope
-
-Review frontend systems: design system, SEO implementation, PWA capabilities, performance optimization, and accessibility compliance.
-
-## Specification
-
-### Design System & UX
-
-* Design-system driven UI (tokens for colors, spacing, typography).
-* Dark/light theme support with user preference persistence.
-* **WCAG AA** accessibility compliance.
-* CLS-safe (no layout shift).
-* **Mobile-first** responsive design; desktop-second.
-* Iconify for icons; no emoji in UI content.
-
-### SEO Requirements
-
-* **SEO-first + SSR-first** for indexable/discovery pages.
-* Required metadata:
-  * Title and description (unique per page)
-  * Open Graph tags (og:title, og:description, og:image)
-  * Favicon (multiple sizes)
-  * Canonical URL
-  * robots meta tag
-* `schema.org` structured data where applicable.
-* `sitemap.xml` (auto-generated, up-to-date).
-* `robots.txt` properly configured.
-
-### PWA Capabilities
-
-* Web app manifest with proper icons and theme colors.
-* Service worker with explicit cache correctness.
-* Push notifications using VAPID where applicable.
-* **Service Worker caching boundary is mandatory**: service worker must not cache personalized/sensitive/authorized content.
-* Authenticated and entitlement-sensitive routes must have explicit cache-control and SW rules.
-* SW caching boundaries must be validated by tests to prevent stale or unauthorized state exposure.
-
-### Performance
-
-* Performance must be **measurable and regression-resistant**:
-  * Define and enforce performance budgets for key journeys
-  * Define caching boundaries and correctness requirements across SSR/ISR/static and service worker behavior
-  * Monitor Core Web Vitals and server latency; alert on regressions
-* Target metrics:
-  * LCP < 2.5s
-  * FID < 100ms
-  * CLS < 0.1
-  * TTFB < 600ms
-
-### Guidance System
-
-* Guidance is mandatory for all user-facing features and monetization flows.
-* Must be: discoverable, clear, dismissible with re-entry option.
-* Localized and measurable (track engagement).
-* Governed by eligibility and frequency controls.
-
-## Domain Discovery
-
-After reviewing compliance with spec, explore improvements:
-
-* **Performance wins**: Are there obvious bundle size reductions? Lazy loading opportunities? Image optimization?
-* **SEO gaps**: Missing structured data? Pages not indexed? Slow crawl rate?
-* **PWA enhancement**: Is offline experience meaningful? Are push notifications valuable?
-* **Accessibility**: Beyond AA compliance, are there UX improvements for assistive tech?
-* **Design consistency**: Are there inconsistencies in the design system usage? Rogue styles?
-* **Mobile experience**: Is mobile-first truly implemented? Touch targets adequate?
-
-## Domain Gates
-
-* [ ] Design tokens used consistently (no hardcoded values)
-* [ ] Dark/light theme works correctly
-* [ ] WCAG AA compliance verified
-* [ ] All pages have unique title/description/OG tags
-* [ ] Sitemap.xml exists and is current
-* [ ] Schema.org markup present
-* [ ] Service worker doesn't cache authenticated content
-* [ ] Core Web Vitals within targets
-* [ ] Performance budgets defined and enforced
-* [ ] Guidance system implemented for key flows