nightytidy 0.1.0

package/src/prompts/steps/30-backup-check.md

@@ -0,0 +1,155 @@
+You are running an overnight backup and disaster recovery audit. Your job: answer "If the worst happened right now, could we recover — and how much would we lose?"
+
+This is a READ-ONLY analysis. Do not create branches or modify code/infrastructure/data. Produce a comprehensive recovery posture assessment and generate the recovery documentation the team would desperately wish they had at 3am during an outage.
+
+## Phase 1: Data Asset Inventory
+
+**Step 1: Identify every data store** — search the codebase for every place data lives:
+- Primary database(s) — engine, data, access patterns
+- Cache layers (Redis, Memcached) — reconstructable from primary sources, or used as a primary store?
+- File/object storage (S3, GCS, local filesystem) — uploads, generated docs, media
+- Search indexes (Elasticsearch, Algolia, Typesense) — rebuildable from primary DB?
+- Message queues — messages in-flight representing uncommitted state?
+- Session storage — in-memory, database, or Redis?
+- Logs and audit trails — survive infrastructure failure?
+- Configuration and secrets — vault, env vars, config files, or hardcoded?
+- Third-party service data (Stripe, SendGrid, Auth0, etc.) — is local DB or the third-party the source of truth?
+
+**Step 2: Classify by criticality**
+- **Irreplaceable**: Cannot be reconstructed (user data, transactions, uploads, audit logs)
+- **Reconstructable**: Rebuildable at significant cost/time (search indexes, caches, derived analytics)
+- **Ephemeral**: Loss acceptable (sessions, temp files, rate limit counters)
+
+**Step 3: Assess volume and growth** — for each critical store: approximate size, growth pattern, unbounded growth risks, largest table/collection.
+
+## Phase 2: Backup Coverage Assessment
+
+**Step 1: Find existing backup configurations** — search for:
+- DB backup scripts, cron jobs, IaC backup config (Terraform, CloudFormation — RDS snapshots, S3 versioning)
+- Docker volume backups, backup-related env vars/config/dependencies (pg_dump, restic, velero, etc.)
+- CI/CD backup jobs, backup documentation, cloud provider backup settings
+
+**Step 2: Assess backup coverage per data store**
+For each: Is it backed up? Method? Frequency? Storage location (same server/region/different)? Encrypted? Retention/rotation policy? Ever tested/restored? Point-in-time recovery capability (WAL, binlog, oplog)?
+
+**Step 3: Identify backup gaps** — flag critical stores with:
+- No backup — **CRITICAL**
+- Backups on same infrastructure (doesn't survive infra failure) — **HIGH**
+- Backups never tested — **HIGH**
+- Infrequent backups relative to data change rate — **MEDIUM**
+- No PITR despite high-frequency writes — **MEDIUM**
+- Unencrypted backups containing PII — **MEDIUM**
+
+## Phase 3: Recovery Capability Assessment
+
+**Step 1: RPO analysis** — for each critical store, determine theoretical RPO:
+- Daily backups, no WAL/binlog → up to 24h loss
+- Hourly snapshots → up to 1h
+- Continuous replication/WAL → near-zero
+- No backups → everything since inception (catastrophic)
+
+Flag mismatches against likely business tolerance (e.g., payment system with 24h RPO = unacceptable).
+
+**Step 2: RTO analysis** — estimate total recovery time:
+- New infrastructure provisioning (IaC vs. manual?)
+- DB restoration time (size-dependent)
+- File storage restoration
+- Secrets/env reconfiguration
+- Search index / cache rebuilding
+- Post-restoration verification
+- Total: "everything gone" → "users can use the product"
+
+**Step 3: Single points of failure** — trace critical paths:
+- Single DB instance (no replica), single server/AZ, single file storage location
+- Secrets stored in only one place
+- Bus factor = 1 for ops knowledge
+- Single third-party dependency with no fallback
+- DNS with no redundancy
+
+**Step 4: Infrastructure reproducibility**
+- What's defined as code vs. manual-only?
+- What can be recreated from the repo alone?
+- What requires manual setup (cloud console configs, DNS, SSL, third-party services)?
+
+## Phase 4: Disaster Scenario Analysis
+
+For each scenario below, assess: recovery path, data loss, time to operational, manual steps required, and what info the on-call engineer would need but might not have.
+
+1. **Primary database destroyed** (server failure, accidental deletion, ransomware)
+2. **Application servers destroyed** (redeploy from scratch — can repo alone suffice? What secrets/config/stateful components?)
+3. **File storage destroyed/corrupted** (backups? Reproducible assets? What functionality breaks?)
+4. **Third-party service permanently unavailable** (for each critical dependency: impact, local data sufficiency, coupling level)
+5. **Credential compromise** (rotation without downtime? Process per credential type? Documented procedure?)
+6. **Accidental data corruption / bad migration** (rollback capability? PITR? How to identify affected data? Audit trail?)
+
+## Phase 5: Recovery Documentation
+
+**Generate `docs/DISASTER_RECOVERY.md`** containing:
+1. **Data Store Inventory** — table: | Data Store | Type | Criticality | Backup Method | Frequency | Location | RPO | RTO |
+2. **Recovery Procedures** — per critical store: prerequisites, locating backups, restore commands, verification, failure fallbacks
+3. **Infrastructure Recreation** — from-code vs. manual, env vars/secrets to re-provision
+4. **Credential Rotation Procedures** — per credential: location, generation, dependent services, expected downtime
+5. **Disaster Response Playbooks** — per scenario: detection, triage, recovery, verification, post-incident
+6. **Emergency Contacts & Access** — template for team to fill in; mark gaps with `⚠️ TEAM INPUT NEEDED: [what's missing]`
+
+**Generate `docs/BACKUP_RECOMMENDATIONS.md`** — specific recommendations: what to implement (with tooling), backup testing schedules, monitoring, redundancy additions, estimated effort per item.
+
+## Output
+
+Save report as `audit-reports/30_BACKUP_DISASTER_RECOVERY_REPORT_[run-number]_[date]_[time in user's local time].md`. Increment run number based on existing reports.
+
+### Report Structure
+1. **Executive Summary** — readiness rating (unprepared/minimal/partial/solid/robust), one-sentence worst-case impact statement, top 3 gaps
+2. **Data Asset Inventory** — | Data Store | Engine | Criticality | Size Estimate | Growth Pattern | Backed Up? |
+3. **Backup Coverage** — coverage matrix, critical gaps
+4. **Recovery Capability** — RPO/RTO tables, total system RTO, single points of failure
+5. **Infrastructure Reproducibility** — code vs. manual matrix
+6. **Disaster Scenario Analysis** — summary table + detailed analysis per scenario
+7. **Documentation Generated** — references to generated docs, list of all `⚠️ TEAM INPUT NEEDED` items
+8. **Recommendations** — priority-ordered: what, why, effort, tooling
+
+## Rules
+- Be honest about uncertainty. "No DB backup config found in codebase — could be configured at infrastructure level outside this repo — verify with the team" is better than "There are no backups."
+- When estimating RPO/RTO, state your assumptions clearly.
+- Write recovery docs for someone stressed, tired, and unfamiliar with the system. Step-by-step. No assumed knowledge.
+- Mark everything you can't determine from the codebase with `⚠️ TEAM INPUT NEEDED`.
+- Use web search to research best practices for the specific databases and services the project uses.
+- You have all night. Be thorough.
+
+## Chat Output Requirement
+
+In addition to writing the full report file, you MUST print a summary directly in the conversation when you finish. Do not make the user open the report to get the highlights. The chat summary should include:
+
+### 1. Status Line
+One sentence: what you did, how long it took, and whether all tests still pass.
+
+### 2. Key Findings
+The most important things discovered — bugs, risks, wins, or surprises. Each bullet should be specific and actionable, not vague. Lead with severity or impact.
+
+**Good:** "CRITICAL: No backup configuration found for the primary Postgres database — total data loss risk."
+**Bad:** "Found some issues with backups."
+
+### 3. Changes Made (if applicable)
+Bullet list of what was actually modified, added, or removed. Skip this section for read-only analysis runs.
+
+### 4. Recommendations
+
+If there are legitimately beneficial recommendations worth pursuing right now, present them in a table. Do **not** force recommendations — if the audit surfaced no actionable improvements, simply state that no recommendations are warranted at this time and move on.
+
+When recommendations exist, use this table format:
+
+| # | Recommendation | Impact | Risk if Ignored | Worth Doing? | Details |
+|---|---|---|---|---|---|
+| *Sequential number* | *Short description (≤10 words)* | *What improves if addressed* | *Low / Medium / High / Critical* | *Yes / Probably / Only if time allows* | *1–3 sentences explaining the reasoning, context, or implementation guidance* |
+
+Order rows by risk descending (Critical → High → Medium → Low). Be honest in the "Worth Doing?" column — not everything flagged is worth the engineering time. If a recommendation is marginal, say so.
+
+### 5. Report Location
+State the full path to the detailed report file for deeper review.
+
+---
+
+**Formatting rules for chat output:**
+- Use markdown headers, bold for severity labels, and bullet points for scannability.
+- Do not duplicate the full report contents — just the highlights and recommendations.
+- If you made zero findings in a phase, say so in one line rather than omitting it silently.

package/src/prompts/steps/31-product-polish-ux-friction.md

@@ -0,0 +1,122 @@
+# Product Polish & UX Friction Audit
+
+READ-ONLY analysis. Do not modify any code.
+
+## Ground Rules
+
+- Evaluate as a **user**, not a developer. "The code handles this correctly" is irrelevant if the user can't tell.
+- Be specific: not "onboarding could be better" but "after signup, user lands on an empty dashboard with no guidance."
+- Classify every issue: **broken** / **confusing** / **incomplete** / **missing**.
+- Severity = frequency × pain. Trace every flow.
+
+---
+
+## Phase 1: User Journey Mapping
+
+**Entry points** — Trace each: signup, login, invite link, OAuth, magic link, public pages, shared links, API, CLI, deep links.
+
+**Core journeys per user role:**
+- First use: signup → onboarding → first meaningful action → "aha moment"
+- Core loop: the daily/weekly workflow
+- Configuration: settings, profile, team/org management
+- Edge cases: account recovery, plan changes, data export, deletion
+- Exit points: dead ends, confusing branches, flows that just stop
+
+**Secondary flows** — Notifications, search, filtering, sorting, bulk actions, imports/exports, integrations, billing, admin.
+
+---
+
+## Phase 2: First-Use & Onboarding
+
+**Signup:** Step count, field necessity, email verification clarity (cross-device?), OAuth permission scope & failure fallback, error specificity (duplicate email, weak password, etc.).
+
+**First experience:** What appears post-signup — empty state, tutorial, or sample data? Clear path to first action? Blocking setup steps? Skippable onboarding? Progress saved if user leaves?
+
+**Empty states:** For every list/dashboard/feed — what shows with zero data? Does it guide the user toward populating it?
+
+---
+
+## Phase 3: Core Workflow
+
+**Primary workflow:** Click/step count for common actions. Unnecessary confirmations? Missing confirmations on destructive actions? Undo support? Save clarity (auto vs. manual, feedback)?
+
+**Forms & inputs:** Required/optional marking, inline vs. submit-only validation, sensible defaults, helpful placeholders, error display (all vs. first), input preservation on failure, progress for long forms, timezone/date format clarity.
+
+**Navigation:** Location awareness (breadcrumbs, active states, titles), back-navigation (browser + in-app), information architecture logic, deep link shareability & permissions.
+
+**Feedback & loading:** Immediate feedback on every action? Click-and-nothing-happens cases? Progress for long operations? Safe to navigate away? Retry without re-entry on failure?
+
+---
+
+## Phase 4: Edge Cases & Errors
+
+**Destructive actions:** Confirmation with consequences explained? Undo available & obvious? Cascade effects communicated? Bulk action extra confirmation with count?
+
+**Common error states:** Network offline, session expired (unsaved work?), permission denied (actionable message?), not found (helpful or generic 404?), rate limited (wait guidance?), file upload failures (size/type/network — all communicated?).
+
+**Concurrency:** Two users editing same resource — conflict handling? Multi-tab state sync? Stale data refresh?
+
+**Boundaries:** Long text (truncation/overflow/layout break?), special characters/emoji/RTL, large datasets (1000+ items — pagination/virtualization/performance?), minimum-input functionality.
+
+---
+
+## Phase 5: Settings & Configuration
+
+**Every setting:** Discoverable? Explained? Immediate or requires save? Resettable to default? Dangerous settings guarded?
+
+**Missing settings users would expect:** Notification preferences, display prefs, timezone, language, default views, keyboard shortcuts, data export.
+
+**Account management:** Change email/password/name? Delete account (clear, complete process)? Team invite/role/removal flows? Data fate on leave/deletion?
+
+---
+
+## Phase 6: Notifications
+
+**Inventory all** emails, in-app, push, webhooks: trigger, content quality, user control (opt-out, frequency, channel).
+
+**Transactional:** Welcome email usefulness, password reset clarity & expiry, invite context, billing transparency.
+
+---
+
+## Phase 7: Accessibility Quick Scan
+
+Flag obvious issues only (defer full audit): keyboard-only core flow completion, color-only information, screen reader labels on interactive elements, mobile responsiveness.
+
+---
+
+## Output
+
+Save as `audit-reports/31_PRODUCT_POLISH_REPORT_[run-number]_[date]_[time in user's local time].md`.
+
+### Report Sections
+
+1. **Executive Summary** — Overall polish level (rough/fair/good/polished), worst friction, journey health.
+2. **User Journey Map** — All flows traced, health per flow (smooth / some friction / significant friction / broken).
+3. **Critical Friction Points** — Table: Flow | Location (file/component) | Issue | Severity | Type
+4. **First-Use & Onboarding** — Signup friction, onboarding gaps, empty states.
+5. **Core Workflow** — Step-by-step assessment, friction, feedback, form quality.
+6. **Edge Cases & Errors** — Destructive action safety, error quality, boundaries.
+7. **Settings & Account** — Gaps, account management, configuration polish.
+8. **Notifications** — Inventory, quality, missing notifications, user control.
+9. **Accessibility Notes** — Obvious issues only.
+10. **Recommendations** — Priority-ordered by effort: quick fixes (hours) / medium (days) / larger (weeks).
+
+**Report rules:** Don't pad — if a flow is smooth, say so in one line. Note items requiring a running app as "verify in running app."
+
+---
+
+## Chat Summary (Required)
+
+Print directly in conversation — don't make the user open the file.
+
+1. **Status Line** — One sentence: what you did.
+2. **Key Findings** — Most important friction points, specific and actionable.
+3. **Recommendations** (only if warranted):
+
+| # | Recommendation | Impact | Risk if Ignored | Worth Doing? | Details |
+|---|---|---|---|---|---|
+| *#* | *≤10 words* | *What improves* | *Low/Med/High/Critical* | *Yes/Probably/Only if time* | *1–3 sentences* |
+
+Order by risk descending. Be honest in "Worth Doing?" — if marginal, say so.
+
+4. **Report Location** — Full file path.

package/src/prompts/steps/32-feature-discovery-opportunity.md

@@ -0,0 +1,128 @@
+# Feature Discovery & Opportunity Audit
+
+Read the entire codebase. Identify features, capabilities, and improvements worth building — grounded purely in what exists, what's partial, and what the architecture supports.
+
+**READ-ONLY. No web search. No code changes.**
+
+---
+
+## Rules
+
+- Every recommendation must reference specific files, models, or patterns.
+- Distinguish: **natural extensions** (80%+ done), **logical additions** (users would expect), **ambitious opportunities** (differentiators).
+- Quality over quantity. 10 well-reasoned opportunities > 50 shallow ones.
+- Be honest about effort and maintenance burden. "Add AI" is not a recommendation — specify data, infrastructure, and minimal viable version.
+- Don't recommend features that conflict with the product's design intent.
+- Prioritize features leveraging existing data/infrastructure over new systems.
+- You have all night. Read everything.
+
+---
+
+## Phase 1: Deep Codebase Understanding
+
+**Product model** — What it does, who it serves, every feature, the full data model (entities, relationships, collected data), user roles/permissions, monetization (free/paid/tiers/gating), integrations.
+
+**Architecture capabilities** — Background jobs, notification systems (email/push/in-app/webhooks), file handling, search (full-text/filtering/faceting), real-time (WebSockets/SSE), API surface & patterns, event/audit tracking.
+
+---
+
+## Phase 2: Unfinished & Abandoned Features
+
+**Partially built features** — Look for:
+- DB tables/columns with no UI or API exposure
+- Models/types defined but unused in routes/components
+- Feature flags permanently off (read the guarded code)
+- Routes/endpoints not linked from UI; unreachable components/pages
+- TODO/FIXME comments describing planned features
+- Migrations adding schema for unfinished features
+- Config/env vars for unintegrated services
+
+For each: what was it, how far did it get, what would finish it?
+
+**Vestigial infrastructure** — Libraries barely used, notification infra sending only one type, permission systems more granular than needed, underutilized search/webhook/queue systems. These are sunk investment awaiting ROI.
+
+---
+
+## Phase 3: Data-Driven Opportunities
+
+**Inventory all collected data** — User actions/events, timestamps, entity relationships, stored-but-unsurfaced metadata, computed-but-undisplayed aggregations.
+
+**Underutilized data** — Analytics/insights, personalization signals, automation triggers, collaborative signals, historical trends. For each: what data exists → what feature it enables → existing pipeline support → effort.
+
+**Missing data** — Features that need data not yet collected. What's the minimal collection that unlocks the most value?
+
+---
+
+## Phase 4: Pattern-Based Feature Discovery
+
+**Generalization** — Hardcoded reports → report builder. Single notification type → configurable system. Fixed workflow → customizable engine. Single integration → framework. Manual admin → self-service. Single export → multi-format. Fixed views → customizable dashboards.
+
+**Cross-entity features** — Unified search, activity feeds, bulk operations, broad tagging/categorization, universal comments/notes, import/export gaps.
+
+**Power user features** — Keyboard shortcuts, saved filters/views, bulk editing, templates, API access, advanced search, custom fields, scheduled/recurring actions.
+
+**Admin & ops** — Missing admin views, audit logging gaps, user impersonation, data export, usage analytics, health dashboards.
+
+---
+
+## Phase 5: Automation & Intelligence
+
+**Automate manual processes** — Repetitive action patterns (macros), predictable status transitions, inferable data entry, condition-triggered notifications, manual cleanup tasks.
+
+**Smart defaults** — Fields users fill identically, likely next actions, adaptive settings, context-based pre-population.
+
+**AI-augmentable features** — Text generation/summarization, manual classification, semantic search, auto-tagging, NL summaries of data, answering questions from product data. For each: what's augmented, what data feeds it, what infra exists, minimal viable version.
+
+---
+
+## Phase 6: Platform Opportunities
+
+**API-as-product** — Is the API exposable to third parties? What internal capabilities would externals pay for? Could webhook/event patterns power an integration ecosystem?
+
+**Multi-tenancy / white-label** — Tenant-aware data model? Configurable branding? Partner resale/embedding potential?
+
+**Extensibility** — Custom fields/views/workflows? Plugin architecture potential? Natural integration boundaries?
+
+---
+
+## Output
+
+Save as `audit-reports/32_FEATURE_DISCOVERY_REPORT_[run-number]_[date]_[time in user's local time].md`.
+
+### Report Structure
+
+1. **Executive Summary** — Maturity assessment, opportunity count by category, top 5 highest-value, overall untapped potential.
+
+2. **Unfinished Features** — Table: Feature | Evidence (files/tables) | Completion % | Effort to Finish | Value | Recommendation
+
+3. **Underutilized Infrastructure** — Table: Infrastructure | Current Usage | Potential Usage | Effort | Value
+
+4. **Data Opportunities** — Underutilized: Data Available | Feature Enabled | Pipeline Support | Effort | Impact. Missing: Feature Desired | Data Needed | Collection Effort
+
+5. **Feature Opportunities** (main deliverable) — Per feature: Name/description, Category (natural extension / logical addition / ambitious), Evidence (specific code references), Existing foundation (% estimate), Effort (days/weeks/months with specifics), Impact, Dependencies, Priority (Critical / High / Medium / Nice-to-have)
+
+6. **Automation & Intelligence** — Manual→automated, smart defaults, AI opportunities with data/infra grounding.
+
+7. **Platform Opportunities** — API, multi-tenancy, extensibility assessments.
+
+8. **Recommended Build Order** — Priority sequence by dependencies and effort-to-value. Group: quick wins (days), medium (weeks), strategic (months).
+
+---
+
+## Chat Summary (Required)
+
+Print directly in conversation — don't make the user open the report.
+
+1. **Status** — One sentence: what you did.
+2. **Key Findings** — Specific, grounded bullets. Lead with value. (e.g., "The `user_events` table tracks every action but nothing surfaces it — a dashboard is low-effort since `jobs/daily_stats.ts` already aggregates.")
+3. **Recommendations** table:
+
+| # | Recommendation | Impact | Risk if Ignored | Worth Doing? | Details |
+|---|---|---|---|---|---|
+| | ≤10 words | What improves | Low–Critical | Yes / Probably / Only if time | 1–3 sentences |
+
+Order by value descending. Be honest — not everything is worth the engineering time. If nothing worth building was found, say so.
+
+4. **Report Location** — Full path to the detailed report.
+
+If a phase yielded zero findings, say so in one line.

package/src/prompts/steps/33-strategic-opportunities.md

@@ -0,0 +1,217 @@
+# Strategic Discovery Night
+
+## Prompt
+
+```
+You are running an overnight strategic analysis of this codebase. You have several hours. Unlike the other overnight runs, this one is less about fixing things and more about discovering opportunities — competitive gaps, feature ideas, and architectural possibilities the team may not have considered.
+
+This is a read-only analysis. Do not create a branch or modify any code.
+
+## Your Mission
+
+### Phase 1: Product Understanding
+
+Before you can identify opportunities, you need to deeply understand what this product does and who it serves.
+
+**Step 1: Reverse-engineer the product**
+By reading the codebase, answer:
+- What is this product? What problem does it solve?
+- Who are the target users? (Infer from UI copy, feature set, data models, onboarding flows)
+- What are the core features? List every distinct capability.
+- What is the current user journey? (Sign up → onboarding → core usage → retention/engagement loops)
+- What data does the product collect and how is it used?
+- What integrations exist? (Third-party services, APIs, webhooks)
+- What is the monetization model? (Infer from billing code, subscription logic, feature gating)
+- What features are gated behind plans/tiers? What's free vs. paid?
+
+**Step 2: Identify the product's strengths**
+Based on the codebase:
+- What features appear most mature and well-built?
+- Where has the most engineering investment gone?
+- What seems to be the core differentiator?
+
+**Step 3: Identify the product's weaknesses**
+Based on the codebase:
+- What features feel half-built or abandoned? (Incomplete code, unused models, feature flags that are off)
+- Where is the UX weakest?
+- What capabilities are missing that users would likely expect?
+- What data is collected but not used to provide value back to users?
+
+### Phase 2: Competitive & Market Research
+
+**Step 1: Identify competitors**
+Based on your understanding of the product:
+- Search the web for direct competitors (products solving the same problem)
+- Search for indirect competitors (different approaches to the same underlying need)
+- Search for adjacent products (solve a related problem, might expand into this space)
+
+**Step 2: Analyze competitor features**
+For the top 5-8 competitors:
+- What features do they offer that this product doesn't?
+- What features does this product have that they don't?
+- How do they position themselves? (Read their marketing pages, pricing pages)
+- What do their users complain about? (Search for reviews, Reddit threads, G2/Capterra reviews, Twitter complaints)
+- What are they charging? How does their pricing model compare?
+- What recent features have they launched? (Check their changelogs, blogs, social media)
+
+**Step 3: Identify market trends**
+- Search for recent industry analysis, trend reports, or thought leadership in this product's space
+- What capabilities are becoming table stakes?
+- What emerging technologies are competitors adopting?
+- What are users in this space increasingly expecting?
+
+### Phase 3: Feature Opportunity Analysis
+
+**Step 1: Gap analysis**
+Based on Phases 1 and 2, identify features this product is missing:
+
+For each missing feature:
+- What is it?
+- Which competitors have it?
+- How important is it to users? (Based on competitor reviews, user complaints, market trends)
+- How hard would it be to build? (Based on the existing codebase architecture — is the foundation there, or would it require significant new infrastructure?)
+- Priority recommendation: critical / high / medium / nice-to-have
+
+**Step 2: Untapped data opportunities**
+Look at the data the product already collects:
+- What analytics or insights could be derived from existing data that aren't being surfaced to users?
+- What personalization opportunities exist based on user behavior data?
+- What automation could be triggered by patterns in the data?
+- What reporting/dashboards could be built from existing data?
+
+**Step 3: Integration opportunities**
+- What third-party services would complement this product?
+- What integration points exist in the codebase that aren't being used to their full potential?
+- What workflows would benefit from connecting to other tools (Slack, email, calendar, CRM, etc.)?
+
+**Step 4: UX improvement opportunities**
+Based on your codebase analysis:
+- Where are users likely experiencing friction? (Complex forms, multi-step processes, confusing navigation)
+- What tasks take too many steps that could be simplified?
+- Where could AI/automation reduce manual work for users?
+- What onboarding improvements would help new users get value faster?
+
+### Phase 4: Architectural Opportunity Analysis
+
+**Step 1: Scalability assessment**
+- What would break first if the user base 10x'd?
+- Are there architectural bottlenecks that would need to be addressed?
+- What's the current approach to background jobs, queuing, caching?
+- Is the database schema ready for growth? (Missing indexes, inefficient queries, tables that would get too large)
+
+**Step 2: Platform/extensibility opportunities**
+- Could this product benefit from a plugin/extension system?
+- Could parts of this product be exposed as an API for third-party developers?
+- Is there a marketplace or ecosystem opportunity?
+- Could the product support white-labeling or multi-tenancy?
+
+**Step 3: AI integration opportunities**
+Look at the codebase through an AI lens:
+- What manual processes could be augmented or automated with AI?
+- Where could AI improve the user experience? (Smart defaults, auto-categorization, natural language search, recommendations, content generation)
+- What data does the product have that could train useful models?
+- What would an "AI-first" version of this product look like?
+
+## Output Requirements
+
+Create the `audit-reports/` directory in the project root if it doesn't already exist. Save the report as `audit-reports/33_STRATEGIC_DISCOVERY_REPORT_[run-number]_[date]_[time in user's local time].md` (e.g., `33_STRATEGIC_DISCOVERY_REPORT_01_2026-02-16_2129.md`). Increment the run number based on any existing reports with the same name prefix in that folder.
+
+### Report Structure
+
+1. **Product Profile**
+- What the product is and does (as understood from the codebase)
+- Target users
+- Core features inventory
+- Strengths and weaknesses
+- Current monetization model
+
+2. **Competitive Landscape**
+- Competitor matrix: table with | Competitor | Overlap | Unique Strengths | Weaknesses | Pricing |
+- What competitors are doing that this product isn't
+- What this product does better than competitors
+- Market trends affecting this space
+
+3. **Feature Opportunities**
+Prioritized list, for each:
+- Feature description
+- User need it addresses
+- Competitive context (who has it, is it table stakes?)
+- Implementation complexity (based on current architecture)
+- Priority: Critical / High / Medium / Nice-to-have
+- Estimated effort: Small (days) / Medium (weeks) / Large (months)
+
+4. **Untapped Data & Intelligence**
+- Data currently collected but underutilized
+- Analytics/insights that could be surfaced
+- Personalization opportunities
+- Automation triggers
+
+5. **Integration & Ecosystem Opportunities**
+- Third-party integrations worth building
+- API/platform possibilities
+- Ecosystem plays
+
+6. **AI Integration Roadmap**
+- AI opportunities ranked by impact and feasibility
+- What data assets exist to support AI features
+- Quick AI wins vs. larger AI initiatives
+
+7. **Architectural Recommendations**
+- Scalability concerns and suggested remediation
+- Platform/extensibility opportunities
+- Technical investments that would unlock future product capabilities
+
+8. **Recommended Roadmap**
+- Synthesize all findings into a suggested priority order
+- Group into: This quarter / Next quarter / Future
+- Note dependencies between items
+
+## Rules
+- This is READ-ONLY. Do not modify any code.
+- Use web search to research competitors, market trends, and user feedback
+- Be honest about uncertainty — mark items as "needs validation" when you're inferring rather than knowing
+- Don't just list every possible feature — prioritize ruthlessly based on user impact and implementation feasibility
+- When assessing implementation complexity, be specific about what exists in the codebase vs. what would need to be built
+- Ground your recommendations in evidence (competitor data, user feedback, market trends, codebase analysis) — not just opinions
+- Consider both quick wins and strategic bets
+- Think like a product manager AND an engineer — the best opportunities are at the intersection of user value and technical feasibility
+- You have all night. Do thorough research.
+```
+
+## Chat Output Requirement
+
+In addition to writing the full report file, you MUST print a summary directly in the conversation when you finish. Do not make the user open the report to get the highlights. The chat summary should include:
+
+### 1. Status Line
+One sentence: what you did, how long it took, and whether all tests still pass.
+
+### 2. Key Findings
+The most important things discovered — bugs, risks, wins, or surprises. Each bullet should be specific and actionable, not vague. Lead with severity or impact.
+
+**Good:** "CRITICAL: No backup configuration found for the primary Postgres database — total data loss risk."
+**Bad:** "Found some issues with backups."
+
+### 3. Changes Made (if applicable)
+Bullet list of what was actually modified, added, or removed. Skip this section for read-only analysis runs.
+
+### 4. Recommendations
+
+If there are legitimately beneficial recommendations worth pursuing right now, present them in a table. Do **not** force recommendations — if the audit surfaced no actionable improvements, simply state that no recommendations are warranted at this time and move on.
+
+When recommendations exist, use this table format:
+
+| # | Recommendation | Impact | Risk if Ignored | Worth Doing? | Details |
+|---|---|---|---|---|---|
+| *Sequential number* | *Short description (≤10 words)* | *What improves if addressed* | *Low / Medium / High / Critical* | *Yes / Probably / Only if time allows* | *1–3 sentences explaining the reasoning, context, or implementation guidance* |
+
+Order rows by risk descending (Critical → High → Medium → Low). Be honest in the "Worth Doing?" column — not everything flagged is worth the engineering time. If a recommendation is marginal, say so.
+
+### 5. Report Location
+State the full path to the detailed report file for deeper review.
+
+---
+
+**Formatting rules for chat output:**
+- Use markdown headers, bold for severity labels, and bullet points for scannability.
+- Do not duplicate the full report contents — just the highlights and recommendations.
+- If you made zero findings in a phase, say so in one line rather than omitting it silently.