@sylphx/flow 2.10.0 → 2.12.0

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # @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
+
+- **commands:** add tech stack and replace checklists with exploration questions ([0772b1d](https://github.com/SylphxAI/flow/commit/0772b1d788ddf2074729d04e67ef3d94b138de10))
+
 ## 2.10.0 (2025-12-17)
 
 Replace saas-* commands with 24 focused /review-* commands.

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,40 +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 threats users can't protect themselves from.
 
-## Review Scope
+## Tech Stack
 
-### Membership and Account Security
+* **Auth**: better-auth
+* **Framework**: Next.js
 
-* 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
+## Non-Negotiables
 
-### Security Event Management
+* Session/device visibility and revocation must exist
+* All security-sensitive actions must be server-enforced and auditable
+* Account recovery must require step-up verification
 
-* Login attempts (success/failure) logged
-* Password changes logged
-* MFA enrollment/removal logged
-* Session creation/revocation logged
-* Suspicious activity detection
-* Security event notifications
+## 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.
 
-## Verification Checklist
+## Driving Questions
 
-- [ ] Session/device visibility exists
-- [ ] Session revocation works
-- [ ] MFA management available
-- [ ] Identity provider linking visible
-- [ ] Security events logged and visible
-- [ ] Recovery flow is secure and audited
+* 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,43 +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 operational gaps and safety improvements.
 
-## Review Scope
+## Tech Stack
 
-### Admin Platform (Operational-Grade)
+* **Framework**: Next.js
+* **API**: tRPC
+* **Database**: Neon (Postgres)
 
-* Baseline: RBAC (least privilege), audit logs, feature flags governance, optional impersonation with safeguards and auditing.
+## Non-Negotiables
 
-### Admin Bootstrap (Critical)
+* 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
 
-* 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.
+## Context
 
-### Configuration Management (Mandatory)
+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.
 
-* 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.
+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?
 
-### Admin Analytics and Reporting (Mandatory)
+## Driving Questions
 
-* Provide 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 when derived from privileged actions.
-
-### 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; reversibility must follow domain rules.
-
-## Verification Checklist
-
-- [ ] RBAC implemented (least privilege)
-- [ ] Admin bootstrap secure (not file seeding)
-- [ ] Bootstrap disables after completion
-- [ ] Config management with history
-- [ ] Feature flags governed
-- [ ] Admin dashboards exist
-- [ ] Impersonation has safeguards
-- [ ] All admin actions audited
+* 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,36 +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 security gaps and UX friction in auth flows.
 
-## Review Scope
+## Tech Stack
 
-### Identity, Verification, and Sign-in
+* **Auth**: better-auth
+* **Framework**: Next.js
 
-* 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.
+## Non-Negotiables
 
-### Verification Requirements
+* 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)
 
-* **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.
+## Context
 
-### Authentication Best Practices
+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.
 
-* Secure session management
-* Token rotation and expiry
-* Brute force protection
-* Account enumeration prevention
-* Secure password reset flow
-* Remember me functionality (secure)
+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?
 
-## Verification Checklist
+## Driving Questions
 
-- [ ] All SSO providers implemented
-- [ ] Missing provider secrets hide UI option
-- [ ] Multi-provider linking works safely
-- [ ] Passkeys (WebAuthn) supported
-- [ ] Email verification enforced
-- [ ] Phone verification optional/step-up
-- [ ] Session management secure
+* 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,36 +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 reliability improvements.
 
-## Review Scope
+## Tech Stack
 
-### Billing and Payments (Stripe)
+* **Payments**: Stripe
+* **Workflows**: Upstash Workflows + QStash
 
-* 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.
+## Non-Negotiables
 
-### Webhook Requirements (High-Risk)
+* 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
 
-* 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 (event ordering is not guaranteed even for the same subscription)
+## Context
 
-### State Machine
+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.
 
-* Define mapping: **Stripe state → internal subscription state → entitlements**
-* Handle: trial, past_due, unpaid, canceled, refund, dispute
-* UI only shows interpretable, non-ambiguous states
+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?
 
-## Verification Checklist
+## Driving Questions
 
-- [ ] Billing state machine defined
-- [ ] Webhook signature verification
-- [ ] Idempotent webhook handling (event id)
-- [ ] Out-of-order handling defined
-- [ ] All Stripe states mapped
-- [ ] UI reflects server-truth only
-- [ ] Refund/dispute handling works
+* What happens when webhooks arrive out of order?
+* Where could revenue leak (failed renewals, unhandled states)?
+* What billing states are confusing to users?
+* How are disputes and chargebacks handled end-to-end?
+* 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,52 +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 code that works but shouldn't exist in its current form.
 
-## Review Scope
-
-### Non-Negotiable Engineering Principles
-
-* 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.
-
-### Tooling Baseline
-
-* **Bun** for runtime
-* **Biome** for linting/formatting
-* **Bun test** for testing
-* Strict TypeScript
-
-### CI Requirements
-
-* Biome lint/format passes
-* Strict TS typecheck passes
-* Unit + E2E tests pass
-* Build succeeds
-
-### Code Quality Best Practices
-
-* Consistent code style
-* Meaningful variable/function names
-* Single responsibility principle
-* DRY (Don't Repeat Yourself)
-* SOLID principles
-* No circular dependencies
-* Reasonable file sizes
-* Clear module boundaries
-
-## Verification Checklist
-
-- [ ] Biome lint passes
-- [ ] Biome format passes
-- [ ] TypeScript strict mode
-- [ ] No type errors
-- [ ] Tests exist and pass
-- [ ] Build succeeds
-- [ ] No TODOs/hacks
-- [ ] No dead code
-- [ ] Packages up to date
+## Tech Stack
+
+* **Runtime**: Bun
+* **Linting/Formatting**: Biome
+* **Testing**: Bun test
+* **Language**: TypeScript (strict)
+
+## Non-Negotiables
+
+* No TODOs, hacks, or workarounds in production code
+* Strict TypeScript with end-to-end type safety (DB → API → UI)
+* No dead or unused code
+
+## Context
+
+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.
+
+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,25 +12,33 @@ 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 architectural weaknesses that will cause problems at scale.
 
-## Review Scope
+## Tech Stack
 
-### Boundaries, Server Enforcement, and Consistency Model (Hard Requirement)
+* **API**: tRPC
+* **Framework**: Next.js
+* **Database**: Neon (Postgres)
+* **ORM**: Drizzle
 
-* 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.
+## Non-Negotiables
 
-## Verification Checklist
+* 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)
 
-- [ ] Clear domain boundaries defined
-- [ ] Server enforcement for all authorization
-- [ ] Explicit consistency model documented
-- [ ] State machine for billing/entitlements exists
-- [ ] No dual-write violations
-- [ ] Auditability chain implemented
+## Context
+
+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?"
+
+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,33 +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 schema problems that will hurt at scale.
 
-## Review Scope
+## Tech Stack
 
-### Drizzle Migrations (Non-Negotiable)
+* **Database**: Neon (Postgres)
+* **ORM**: Drizzle
 
-* 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.
+## Non-Negotiables
 
-### Database Best Practices
+* 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
 
-* Schema design follows normalization principles where appropriate
-* Indexes exist for commonly queried columns
-* Foreign key constraints are properly defined
-* No orphaned tables or columns
-* Proper use of data types (no stringly-typed data)
-* Timestamps use consistent timezone handling
+## Context
 
-## Verification Checklist
+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.
 
-- [ ] All migrations committed and complete
-- [ ] No schema drift detected
-- [ ] CI blocks on migration integrity
-- [ ] Indexes cover common queries
-- [ ] Foreign keys properly defined
-- [ ] Data types appropriate
+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,60 +12,35 @@ 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 what could go wrong in production that we're not catching.
 
-## Review Scope
+## Tech Stack
 
-### Delivery Gates and Completion
+* **CI**: GitHub Actions
+* **Testing**: Bun test
+* **Linting**: Biome
+* **Platform**: Vercel
 
-CI must block merges/deploys when failing:
+## Non-Negotiables
 
-#### Code Quality Gates
-- [ ] Biome lint/format passes
-- [ ] Strict TS typecheck passes
-- [ ] Unit + E2E tests pass (Bun test)
-- [ ] Build succeeds
+* 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
 
-#### Data Integrity Gates
-- [ ] Migration integrity checks pass
-- [ ] No schema drift
+## Context
 
-#### i18n Gates
-- [ ] Missing translation keys fail build
-- [ ] `/en/*` returns 301 redirect
-- [ ] hreflang/x-default correct
-- [ ] Sitemap contains only true variants
+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.
 
-#### Performance Gates
-- [ ] Performance budget verification for key journeys
-- [ ] Core Web Vitals within thresholds
-- [ ] Release-blocking regression detection
+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?
 
-#### Security Gates
-- [ ] CSP/HSTS/security headers verified
-- [ ] CSRF protection tested
+## Driving Questions
 
-#### Consent Gates
-- [ ] Analytics/marketing consent gating verified
-- [ ] Newsletter eligibility and firing rules tested
-
-### Automation Requirement
-
-**All gates above must be enforced by automated tests or mechanized checks (non-manual); manual verification does not satisfy release gates.**
-
-### Configuration Gates
-
-* Build/startup must fail-fast when required configuration/secrets are missing or invalid for the target environment.
-
-### Operability Gates
-
-* Observability and alerting configured for critical anomalies
-* Workflow dead-letter handling is operable, visible, and supports controlled replay
-
-## Verification Checklist
-
-- [ ] All gates automated (no manual)
-- [ ] CI blocks on failures
-- [ ] Config fail-fast works
-- [ ] Operability gates met
-- [ ] No TODOs/hacks/workarounds
-- [ ] No dead/unused code
+* What could ship to production that shouldn't?
+* Where does manual verification substitute for automation?
+* 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?