@sylphx/flow 2.11.0 → 2.12.0

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # @sylphx/flow
 
+## 2.12.0 (2025-12-17)
+
+### ✨ Features
+
+- **commands:** add trust-safety and fill SSOT gaps ([fe67913](https://github.com/SylphxAI/flow/commit/fe67913db8183ae6c16070825f61744cf44acafa))
+
 ## 2.11.0 (2025-12-17)
 
 ### ✨ Features

package/assets/slash-commands/review-account-security.md

@@ -1,6 +1,6 @@
 ---
 name: review-account-security
-description: Review account security - sessions, devices, MFA, security events
+description: Review account security - sessions, MFA, devices, security events
 agent: coder
 ---
 
@@ -12,37 +12,30 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify improvements for user safety and threat detection.
+* **Explore beyond the spec**: identify threats users can't protect themselves from.
 
 ## Tech Stack
 
 * **Auth**: better-auth
 * **Framework**: Next.js
 
-## Review Scope
+## Non-Negotiables
 
-### Membership and Account Security
+* Session/device visibility and revocation must exist
+* All security-sensitive actions must be server-enforced and auditable
+* Account recovery must require step-up verification
 
-* Membership is entitlement-driven and server-enforced.
-* Provide a dedicated **Account Security** surface.
-* **Account Security minimum acceptance**:
-  * 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
+## Context
 
-### Recovery Governance
+Account security is about giving users control over their own safety. Users should be able to see what's accessing their account, remove suspicious sessions, and understand when something unusual happens.
 
-* Account recovery flow secure
-* Support-assisted recovery with strict audit logging
-* Step-up verification for sensitive actions
+But it's also about protecting users from threats they don't know about. Compromised credentials, session hijacking, social engineering attacks on support — these require proactive detection, not just user vigilance.
 
-## Key Areas to Explore
+## Driving Questions
 
-* What visibility do users have into their active sessions and devices?
-* How robust is the MFA implementation and enrollment flow?
-* What security events are logged and how accessible are they to users?
-* How does the account recovery flow prevent social engineering attacks?
-* What step-up authentication exists for sensitive actions?
-* How are compromised accounts detected and handled?
+* Can a user tell if someone else has access to their account?
+* What happens when an account is compromised — how fast can we detect and respond?
+* How does the recovery flow prevent social engineering attacks?
+* What security events should trigger user notification?
+* Where are we relying on user vigilance when we should be detecting threats?
+* What would a truly paranoid user want that we don't offer?

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

@@ -1,6 +1,6 @@
 ---
 name: review-admin
-description: Review admin - RBAC, bootstrap, config management, feature flags
+description: Review admin - RBAC, bootstrap, audit, operational tools
 agent: coder
 ---
 
@@ -12,7 +12,7 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify operational improvements and safety enhancements.
+* **Explore beyond the spec**: identify operational gaps and safety improvements.
 
 ## Tech Stack
 
@@ -20,39 +20,24 @@ agent: coder
 * **API**: tRPC
 * **Database**: Neon (Postgres)
 
-## Review Scope
+## Non-Negotiables
 
-### Admin Platform (Operational-Grade)
+* Admin bootstrap must use secure allowlist, not file seeding; must be permanently disabled after first admin
+* All privilege grants must be audited (who/when/why)
+* Actions affecting money/access/security require step-up controls
+* Secrets must never be exposed through admin UI
 
-* Baseline: RBAC (least privilege), audit logs, feature flags governance, optional impersonation with safeguards and auditing.
+## Context
 
-### Admin Bootstrap (Critical)
+The admin platform is where operational power lives — and where operational mistakes happen. A well-designed admin reduces the chance of human error while giving operators the tools they need to resolve issues quickly.
 
-* 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.
-  * 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.
+Consider: what does an operator need at 3am when something is broken? What would prevent an admin from accidentally destroying data? How do we know if someone is misusing admin access?
 
-### Configuration Management (Mandatory)
+## Driving Questions
 
-* All **non-secret** product-level configuration must be manageable via admin (server-enforced), with validation and change history.
-* Secrets/credentials are environment-managed only; admin may expose safe readiness/health visibility, not raw secrets.
-
-### Admin Analytics and Reporting (Mandatory)
-
-* Provide comprehensive dashboards/reports for business, growth, billing, referral, support, and security/abuse signals, governed by RBAC.
-
-### Admin Operational Management (Mandatory)
-
-* Tools for user/account management, entitlements/access management, lifecycle actions, and issue resolution workflows.
-* Actions affecting access, money/credits, or security posture require appropriate step-up controls and must be fully auditable.
-
-## Key Areas to Explore
-
-* How secure is the admin bootstrap process?
-* What RBAC gaps exist that could lead to privilege escalation?
-* How comprehensive is the audit logging for sensitive operations?
-* What admin workflows are missing or painful?
-* How does impersonation work and what safeguards exist?
-* What visibility do admins have into system health and issues?
+* What would an operator need during an incident that doesn't exist today?
+* Where could an admin accidentally cause serious damage?
+* How would we detect if admin access was compromised or misused?
+* What repetitive admin tasks should be automated?
+* Where is audit logging missing or insufficient?
+* What would make the admin experience both safer and faster?

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

@@ -1,6 +1,6 @@
 ---
 name: review-auth
-description: Review authentication - SSO providers, passkeys, verification, sign-in
+description: Review authentication - sign-in, SSO, passkeys, verification
 agent: coder
 ---
 
@@ -12,31 +12,30 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify improvements for security, usability, and reliability.
+* **Explore beyond the spec**: identify security gaps and UX friction in auth flows.
 
 ## Tech Stack
 
 * **Auth**: better-auth
 * **Framework**: Next.js
 
-## Review Scope
+## Non-Negotiables
 
-### Identity, Verification, and Sign-in
+* All authorization decisions must be server-enforced (no client-trust)
+* Email verification required for high-impact capabilities
+* If SSO provider secrets are missing, hide the option (no broken UI)
 
-* 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) are first-class with secure enrollment/usage/recovery.
+## Context
 
-### Verification Requirements
+Authentication is the front door to every user's data. It needs to be both secure and frictionless — a difficult balance. Users abandon products with painful sign-in flows, but weak auth leads to compromised accounts.
 
-* **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.
+Consider the entire auth journey: first sign-up, return visits, account linking, recovery flows. Where is there unnecessary friction? Where are there security gaps? What would make auth both more secure AND easier?
 
-## Key Areas to Explore
+## Driving Questions
 
-* How does the current auth implementation compare to best practices?
-* What security vulnerabilities exist in the sign-in flows?
-* How can the user experience be improved while maintaining security?
-* What edge cases are not handled (account recovery, provider outages, etc.)?
-* How does session management handle concurrent devices?
+* What's the sign-in experience for a first-time user vs. returning user?
+* Where do users get stuck or abandon the auth flow?
+* What happens when a user loses access to their primary auth method?
+* How does the system handle auth provider outages gracefully?
+* What would passwordless-first auth look like here?
+* Where is auth complexity hiding bugs or security issues?

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

@@ -1,6 +1,6 @@
 ---
 name: review-billing
-description: Review billing - Stripe integration, webhooks, state machine
+description: Review billing - Stripe integration, webhooks, subscription state
 agent: coder
 ---
 
@@ -12,41 +12,32 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify revenue leakage and billing reliability improvements.
+* **Explore beyond the spec**: identify revenue leakage and reliability improvements.
 
 ## Tech Stack
 
 * **Payments**: Stripe
 * **Workflows**: Upstash Workflows + QStash
 
-## Review Scope
+## Non-Negotiables
 
-### Billing and Payments (Stripe)
+* Webhook signature must be verified (reject unverifiable events)
+* Stripe event ID must be used for idempotency
+* Webhooks must handle out-of-order delivery
+* No dual-write: billing truth comes from Stripe events only
+* UI must only display states derivable from server-truth
 
-* Support subscriptions and one-time payments as product needs require.
-* **Billing state machine follows mapping requirements**; UI must only surface explainable, non-ambiguous states aligned to server-truth.
-* Tax/invoicing and refund/dispute handling must be behaviorally consistent with product UX and entitlement state.
+## Context
 
-### Webhook Requirements (High-Risk)
+Billing is where trust meets money. A bug here isn't just annoying — it's a financial and legal issue. Users must always see accurate state, and the system must never lose or duplicate charges.
 
-* Webhooks must be idempotent, retry-safe, out-of-order safe, auditable
-* Billing UI reflects server-truth state without ambiguity
-* **Webhook trust is mandatory**: 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
+Beyond correctness, consider the user experience of billing. Is the upgrade path frictionless? Are failed payments handled gracefully? Does the dunning process recover revenue or just annoy users?
 
-### State Machine
+## Driving Questions
 
-* Define mapping: **Stripe state → internal subscription state → entitlements**
-* Handle: trial, past_due, unpaid, canceled, refund, dispute
-* UI only shows interpretable, non-ambiguous states
-
-## Key Areas to Explore
-
-* How robust is the webhook handling for all Stripe events?
 * What happens when webhooks arrive out of order?
-* How does the UI handle ambiguous billing states?
-* What revenue leakage exists (failed renewals, dunning, etc.)?
+* Where could revenue leak (failed renewals, unhandled states)?
+* What billing states are confusing to users?
 * How are disputes and chargebacks handled end-to-end?
-* What is the testing strategy for billing edge cases?
+* If Stripe is temporarily unavailable, what breaks?
+* What would make the billing experience genuinely excellent?

package/assets/slash-commands/review-code-quality.md

@@ -1,6 +1,6 @@
 ---
 name: review-code-quality
-description: Review code quality - linting, TypeScript, testing, CI
+description: Review code quality - architecture, types, testing, maintainability
 agent: coder
 ---
 
@@ -12,7 +12,7 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify maintainability issues and technical debt.
+* **Explore beyond the spec**: identify code that works but shouldn't exist in its current form.
 
 ## Tech Stack
 
@@ -21,24 +21,23 @@ agent: coder
 * **Testing**: Bun test
 * **Language**: TypeScript (strict)
 
-## Review Scope
+## Non-Negotiables
 
-### Non-Negotiable Engineering Principles
+* No TODOs, hacks, or workarounds in production code
+* Strict TypeScript with end-to-end type safety (DB → API → UI)
+* No dead or unused code
 
-* No workarounds, hacks, or TODOs.
-* Feature-first with clean architecture; designed for easy extension; no "god files".
-* Type-first, strict end-to-end correctness (**DB → API → UI**).
-* Serverless-first and server-first; edge-compatible where feasible without sacrificing correctness, security, or observability.
-* Mobile-first responsive design; desktop-second.
-* Precise naming; remove dead/unused code.
-* Upgrade all packages to latest stable; avoid deprecated patterns.
+## Context
 
-## Key Areas to Explore
+Code quality isn't about following rules — it's about making the codebase a place where good work is easy and bad work is hard. High-quality code is readable, testable, and changeable. Low-quality code fights you on every change.
 
-* What areas of the codebase have the most technical debt?
-* Where are types weak or using `any` inappropriately?
-* What test coverage gaps exist for critical paths?
-* What code patterns are inconsistent across the codebase?
-* What dependencies are outdated or have known vulnerabilities?
-* Where do "god files" or overly complex modules exist?
-* What naming inconsistencies make the code harder to understand?
+Don't just look for rule violations. Look for code that technically works but is confusing, fragile, or painful to modify. Look for patterns that will cause bugs. Look for complexity that doesn't need to exist.
+
+## Driving Questions
+
+* What code would you be embarrassed to show a senior engineer?
+* Where is complexity hiding that makes the codebase hard to understand?
+* What would break if someone new tried to make changes here?
+* Where are types lying (as any, incorrect generics, missing null checks)?
+* What test coverage gaps exist for code that really matters?
+* If we could rewrite one part of this codebase, what would have the highest impact?

package/assets/slash-commands/review-data-architecture.md

@@ -1,6 +1,6 @@
 ---
 name: review-data-architecture
-description: Review data architecture - boundaries, consistency model, server enforcement
+description: Review data architecture - boundaries, consistency, state machines
 agent: coder
 ---
 
@@ -12,7 +12,7 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify improvements for consistency, reliability, and scalability.
+* **Explore beyond the spec**: identify architectural weaknesses that will cause problems at scale.
 
 ## Tech Stack
 
@@ -21,23 +21,24 @@ agent: coder
 * **Database**: Neon (Postgres)
 * **ORM**: Drizzle
 
-## Review Scope
+## Non-Negotiables
 
-### Boundaries, Server Enforcement, and Consistency Model (Hard Requirement)
+* All authorization must be server-enforced (no client-trust)
+* No dual-write: billing/entitlement truth comes from Stripe events only
+* UI must never contradict server-truth
+* High-value mutations must have audit trail (who/when/why/before/after)
 
-* Define clear boundaries: domain rules, use-cases, integrations, UI.
-* All authorization/entitlements are **server-enforced**; no client-trust.
-* Runtime constraints (serverless/edge) must be explicit and validated.
-* **Consistency model is mandatory for high-value state**: for billing, entitlements, ledger, admin privilege grants, and security posture, the system must define and enforce an explicit consistency model (source-of-truth, allowed delay windows, retry/out-of-order handling, and acceptable eventual consistency bounds).
-* **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.
-* **Server-truth is authoritative**: UI state must never contradict server-truth. Where asynchronous confirmation exists, UI must represent that state unambiguously and remain explainable.
-* **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.
+## Context
 
-## Key Areas to Explore
+Data architecture determines what's possible and what's painful. Good architecture makes new features easy; bad architecture makes everything hard. The question isn't "does it work today?" but "will it work when requirements change?"
 
-* How well are domain boundaries defined and enforced?
-* Where does client-side trust leak into authorization decisions?
-* What consistency guarantees exist and are they sufficient?
-* How does the system handle eventual consistency edge cases?
-* What would break if a webhook is processed out of order?
+Consider the boundaries between domains, the flow of data through the system, and the consistency guarantees at each step. Where are implicit assumptions that will break? Where is complexity hidden that will cause bugs?
+
+## Driving Questions
+
+* If we were designing this from scratch, what would be different?
+* Where will the current architecture break as the product scales?
+* What implicit assumptions are waiting to cause bugs?
+* How do we know when state is inconsistent, and how do we recover?
+* Where is complexity hiding that makes the system hard to reason about?
+* What architectural decisions are we avoiding that we shouldn't?

package/assets/slash-commands/review-database.md

@@ -1,6 +1,6 @@
 ---
 name: review-database
-description: Review database - Drizzle migrations, schema drift, CI gates
+description: Review database - schema, migrations, performance, reliability
 agent: coder
 ---
 
@@ -8,30 +8,34 @@ agent: coder
 
 ## Mandate
 
-* Perform a **deep, thorough review** of database architecture in this codebase.
+* Perform a **deep, thorough review** of the database in this codebase.
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify improvements for performance, reliability, and maintainability.
+* **Explore beyond the spec**: identify schema problems that will hurt at scale.
 
 ## Tech Stack
 
 * **Database**: Neon (Postgres)
 * **ORM**: Drizzle
 
-## Review Scope
+## Non-Negotiables
 
-### Drizzle Migrations (Non-Negotiable)
+* Migration files must exist, be complete, and be committed
+* CI must fail if schema changes aren't represented by migrations
+* No schema drift between environments
 
-* Migration files must exist, be complete, and be committed.
-* Deterministic, reproducible, environment-safe; linear/auditable history; no drift.
-* CI must fail if schema changes are not represented by migrations.
+## Context
 
-## Key Areas to Explore
+The database schema is the foundation everything else is built on. A bad schema creates friction for every feature built on top of it. Schema changes are expensive and risky — it's worth getting the design right.
 
-* Is the schema well-designed for the domain requirements?
-* Are there missing indexes that could improve query performance?
-* How are database connections pooled and managed?
-* What is the backup and disaster recovery strategy?
-* Are there any N+1 query problems or inefficient access patterns?
-* How does the schema handle soft deletes, auditing, and data lifecycle?
+Consider not just "does the schema work?" but "does this schema make the right things easy?" Are the relationships correct? Are we storing data in ways that will be painful to query? Are we missing constraints that would prevent bugs?
+
+## Driving Questions
+
+* If we were designing the schema from scratch, what would be different?
+* Where are missing indexes causing slow queries we haven't noticed yet?
+* What data relationships are awkward or incorrectly modeled?
+* How does the schema handle data lifecycle (soft deletes, archival, retention)?
+* What constraints are missing that would prevent invalid state?
+* Where will the current schema hurt at 10x or 100x scale?

package/assets/slash-commands/review-delivery.md

@@ -1,10 +1,10 @@
 ---
 name: review-delivery
-description: Review delivery gates - release blocking checks, verification
+description: Review delivery - CI gates, automated verification, release safety
 agent: coder
 ---
 
-# Delivery Gates Review
+# Delivery Review
 
 ## Mandate
 
@@ -12,7 +12,7 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify gaps in automated verification and release safety.
+* **Explore beyond the spec**: identify what could go wrong in production that we're not catching.
 
 ## Tech Stack
 
@@ -21,37 +21,26 @@ agent: coder
 * **Linting**: Biome
 * **Platform**: Vercel
 
-## Review Scope
+## Non-Negotiables
 
-### Delivery Gates and Completion
+* All release gates must be automated (manual verification doesn't count)
+* Build must fail-fast on missing required configuration
+* CI must block on: lint, typecheck, tests, build
+* `/en/*` must redirect (no duplicate content)
+* Security headers (CSP, HSTS) must be verified by tests
+* Consent gating must be verified by tests
 
-CI must block merges/deploys when failing:
+## Context
 
-* Code Quality: Biome lint/format, strict TS typecheck, unit + E2E tests, build
-* Data Integrity: Migration integrity checks, no schema drift
-* i18n: Missing translation keys fail build, `/en/*` redirects, hreflang correct
-* Performance: Budget verification, Core Web Vitals thresholds, regression detection
-* Security: CSP/HSTS/headers verified, CSRF protection tested
-* Consent: Analytics/marketing consent gating verified
+Delivery gates are the last line of defense before code reaches users. Every manual verification step is a gate that will eventually fail. Every untested assumption is a bug waiting to ship.
 
-### Automation Requirement
+The question isn't "what tests do we have?" but "what could go wrong that we wouldn't catch?" Think about the deploy that breaks production at 2am — what would have prevented it?
 
-**All gates above must be enforced by automated tests or mechanized checks (non-manual); manual verification does not satisfy release gates.**
+## Driving Questions
 
-### Configuration Gates
-
-* Build/startup must fail-fast when required configuration/secrets are missing or invalid.
-
-### Operability Gates
-
-* Observability and alerting configured for critical anomalies
-* Workflow dead-letter handling is operable and supports controlled replay
-
-## Key Areas to Explore
-
-* What release gates are missing or insufficient?
+* What could ship to production that shouldn't?
 * Where does manual verification substitute for automation?
-* How fast is the CI pipeline and what slows it down?
-* What flaky tests exist and how do they affect reliability?
-* How does the deployment process handle rollbacks?
-* What post-deployment verification exists?
+* What flaky tests are training people to ignore failures?
+* How fast is the feedback loop, and what slows it down?
+* If a deploy breaks production, how fast can we detect and rollback?
+* What's the worst thing that shipped recently that tests should have caught?

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

@@ -1,6 +1,6 @@
 ---
 name: review-discovery
-description: Review discovery - competitive research, features, pricing opportunities
+description: Review discovery - competitive research, opportunities, market positioning
 agent: coder
 ---
 
@@ -8,27 +8,31 @@ agent: coder
 
 ## Mandate
 
-* Perform a **deep, thorough review** to discover opportunities in this codebase.
+* Perform a **deep, thorough review** to discover opportunities for this product.
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: this review IS the exploration—think broadly and creatively.
+* **This review IS exploration** — think broadly and creatively about what could be.
 
-## Review Scope
+## Tech Stack
 
-### Review Requirements: Explore Beyond the Spec
+* Research across the product's full stack as needed
 
-* **Feature design review**: define success criteria, journeys, state model, auth/entitlements, instrumentation; propose competitiveness improvements within constraints.
-* **Pricing/monetization review**: packaging/entitlements, lifecycle semantics, legal/tax/invoice implications; propose conversion/churn improvements within constraints.
-* **Competitive research**: features, extensibility, guidance patterns, pricing/packaging norms; convert insights into testable acceptance criteria.
+## Non-Negotiables
 
-## Key Areas to Explore
+* None — this is pure exploration
 
-* What features are competitors offering that we lack?
-* What pricing models are common in the market and how do we compare?
-* What UX patterns are users expecting based on industry standards?
+## Context
+
+Discovery is about finding what's missing, what's possible, and what would make the product significantly more competitive. It's not about fixing bugs — it's about identifying opportunities that don't yet exist.
+
+Look at competitors, market trends, user expectations, and technological possibilities. What would make users choose this product over alternatives? What capabilities would unlock new business models?
+
+## Driving Questions
+
+* What are competitors doing that we're not?
+* What do users expect based on industry standards that we lack?
 * What integrations would add significant value?
-* What automation opportunities exist to reduce manual work?
-* What self-service capabilities are users asking for?
+* What pricing models are common in the market and how do we compare?
 * What technical capabilities could enable new business models?
-* Where are the biggest gaps between current state and market expectations?
+* What would make this product a category leader rather than a follower?