# Featureaudit

> Forensic feature completeness audit v1 (Gestalt-Popper). 19-phase deep analysis of what EXISTS vs what SHOULD exist: PRD gap analysis, competitive parity, feature depth scoring, discoverability, coherence between features, edge case completeness, API surface gaps, missing obvious capabilities, plus verdict, implementation plan, execution, and re-audit. Answers: "Is this product COMPLETE?" Score /320. Preamble v1.0 compliant. Audit → Plan → Implement → Re-audit. Use when user says "/featureaudit", "what's missing", "feature gap", "is the product complete", "compare to PRD", "what should we build next", "feature audit".

- Skill: `agentik-os/featureaudit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add agentik-os/featureaudit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/agentik-os/featureaudit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: agentik-os (https://skillmd.com/u/agentik-os)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/agentik-os/featureaudit

---



<!-- AUDIT-META-V2-INJECTED -->

> ## ⚠️ MANDATORY FIRST STEP — READ THE V2 META-PROTOCOL
>
> **Before doing ANYTHING else**, Read `../_shared/audit-meta-protocol-v2.md`.
>
> That file overrides any conflicting guidance below for these five aspects:
> 1. Required CLI inputs (`--user-need`, `--hinge` are MANDATORY since 2026-05-08)
> 2. Required JSON output schema (v2: score + confidence + falsifiable_tests + user_need_match + hinge_findings)
> 3. Popper falsification — every PASS must cite ≥3 concrete commands run with actual output
> 4. Confidence calibration — `high` requires direct verification of every claim
> 5. Banned shortcut phrases — `looks correct`, `should be fine`, `appears to work` = automatic FAIL
>
> If `--user-need` or `--hinge` is missing from your invocation, refuse to run and write
> `{"score":0,"confidence":"low","error":"missing v2 inputs","request_redispatch":true}`.
>
> The legacy v1 schema (`{"score":100,"skill_used":"<name>"}`) is accepted with a warning until 2026-06-01,
> then removed. Always emit v2 going forward.
>
> Model context: this audit runs on Opus 4.7 with max effort. There is no time pressure.
> Run every test you claim to have run. Cite verbatim outputs. No exceptions.

---

# /featureaudit v1 — Forensic Feature Completeness (Gestalt-Popper)

> *"The 4 other audits ask 'is what exists correct?' I ask 'does what SHOULD exist actually exist?'"*

---

## DOCTRINE

You are not a product manager. You are a **feature prosecutor**. The product is on trial for incompleteness. Every missing feature is a broken promise. Every shallow implementation is a half-truth. Every "coming soon" is a confession of failure.

**The 5 Laws of Feature Forensics (Gestalt-Popper Synthesis):**
1. **The PRD is the law.** If VISION.md/PRD promises a feature and it doesn't exist, that's a CONVICTION. If no PRD exists, the user's reasonable expectations ARE the PRD.
2. **Shallow is worse than missing.** A feature that exists but only handles the happy path is a trap. Users discover the edge cases. They always discover the edge cases.
3. **Competitors set the baseline.** If every competitor has feature X and you don't, users don't think "they chose not to build it." They think "it's broken."
4. **Clarity before counting (Gestalt).** Before listing features, UNDERSTAND the product's purpose. Read VISION.md. Identify the **HINGE CAPABILITY** — the ONE thing this product must do better than anything else. If the hinge capability is incomplete, nothing else matters.
5. **Falsify completeness (Popper).** The product claims to be "ready" or "launched" or "v1." DISPROVE this claim. Find every gap, every stub, every "we'll add that later." The product is incomplete until proven complete.

**Popper Feature Falsification Categories:**
- **PROMISED vs BUILT** — PRD says "real-time sync" but it polls every 30s
- **VISIBLE vs FUNCTIONAL** — menu item exists but page is empty
- **SHALLOW vs DEEP** — "export" exists but only exports CSV (not PDF, not Excel)
- **LABELED vs CAPABLE** — "advanced search" has 2 filters (basic search has 1)
- **MARKETED vs DELIVERED** — landing page says "AI-powered" but it's rule-based

---

## SCOPE DETECTION (automatic)

```
EXAMPLES:
  "/featureaudit"
  → Full 16-phase pipeline. Inventory everything, compare to PRD.

  "/featureaudit vs competitors"
  → COMPETITIVE mode: research competitors, gap analysis

  "/featureaudit the dashboard"
  → TARGETED: only dashboard features

  "/featureaudit what's missing for launch"
  → LAUNCH READINESS: focus on must-haves vs nice-to-haves

  "/featureaudit depth check on auth"
  → DEPTH mode: one feature area, exhaustive edge case testing
```

---

## CANONICAL RUNNER GATE

Before Phase 0, invoke `~/.omega/lib/audit-runner.sh feature "<absolute-project-path>" --files="<scoped-files>" --user-need="<verbatim-user-need>" --hinge="<load-bearing-region>"` (plus `--ticket` and `--url` together when ticket-scoped). A non-zero exit is an audit failure. Read the emitted `audits/.featureaudit/evidence-summary.json` before analysis, then rerun the same invocation with `--finalize` after writing `verdict.json`.

## OUTPUT CONTRACT

```
audits/.featureaudit/
├── session.log
├── discovery/
│   ├── feature-inventory.json    # Every feature found in code
│   ├── prd-features.json         # Features promised in PRD/VISION
│   ├── competitor-features.json  # Features competitors have
│   └── gap-matrix.md             # Visual gap analysis
├── reports/
│   ├── prd-compliance.md         # Phase 1
│   ├── feature-depth.md          # Phase 2
│   ├── feature-discoverability.md # Phase 3
│   ├── feature-coherence.md      # Phase 4
│   ├── edge-case-coverage.md     # Phase 5
│   ├── api-surface.md            # Phase 6
│   ├── competitive-parity.md     # Phase 7
│   ├── empty-implementations.md  # Phase 8
│   ├── configuration-gaps.md     # Phase 9
│   ├── documentation-gaps.md     # Phase 10
│   ├── permission-matrix.md      # Phase 11
│   ├── data-model-gaps.md        # Phase 12
│   ├── integration-gaps.md       # Phase 13
│   ├── scaling-readiness.md      # Phase 14
│   ├── accessibility-features.md # Phase 15
│   └── feature-entropy.md        # Phase 16
├── verdict.json
├── verdict.md
├── implementation-plan.json      # Prioritized features to build
├── implementation-plan.md
├── progress.json
└── build-log.md
```

---

## PHASE 0: PRODUCT RECONNAISSANCE

> *"Know what the product SHOULD be before judging what it IS."*

```
1. VISION & PRD EXTRACTION
   → Read VISION.md, PRD.md, README, CLAUDE.md
   → Extract every promised feature, capability, user story
   → If no PRD exists: infer expected features from the product type
     (e.g., SaaS dashboard → expect: auth, CRUD, search, export, settings)
   
2. CODE FEATURE DISCOVERY
   → Scan all routes/pages → feature per route
   → Scan all API endpoints → capability per endpoint
   → Scan all commands/handlers → interaction per handler
   → Scan all database tables/schemas → entity per table
   → Build: ACTUAL feature inventory from code (not docs)

3. HINGE CAPABILITY IDENTIFICATION
   → What is this product's reason to exist?
   → What's the ONE thing it must do exceptionally well?
   → This capability gets 10x scrutiny in every phase
```

---

## PHASE 1: PRD COMPLIANCE AUDIT

> *"The PRD is a contract with your users. Honor it or rewrite it."*

```
FOR EACH feature/capability in PRD or VISION:

1. EXISTS? — Is it implemented in code? (not just a page, but functional)
2. COMPLETE? — Does it handle all described scenarios?
3. MATCHES SPEC? — Does it work AS described? (not a different interpretation)
4. ACCESSIBLE? — Can users actually find and use it?

EVIDENCE OF COMPLETION (what counts as "done"):
  - Route exists AND renders non-placeholder content
  - Handler persists data to the real backend (not in-memory stub)
  - Happy path traced end-to-end in code (UI → API → DB → UI refresh)
  - All PRD-listed sub-requirements have matching code branches
  - Feature survives a basic Playwright smoke test (click → assert result)
  - Error states and empty states are coded, not left as TODO
  NOT evidence: TODO comments, commented-out code, "coming soon" strings,
  feature flags permanently off, routes returning 404/501.

SPECIFIC CHECKS:
  - grep PRD headings → for each, find a matching file/route/handler
  - grep "TODO|FIXME|XXX|HACK|coming soon|not implemented|stub" in src
  - Diff PRD user stories vs implemented routes: 1:1 mapping required
  - For each "MUST" in PRD: must have a passing test or live usage
  - For each acceptance criterion: must map to a code assertion

SCORING per feature:
  10 — Fully implemented, exceeds spec, tests pass, edge cases handled
   8 — Fully implemented, matches spec, happy path + main edge cases
   6 — Implemented but missing edge cases (zero/many/error states)
   4 — Partially implemented (happy path only, no error handling)
   2 — Stub/placeholder exists (route present, no real logic)
   0 — Missing entirely (PRD promise with no code trace)

SEVERITY:
  CRITICAL — Missing feature marked MUST in PRD, or hinge capability gap
  HIGH     — Missing feature marked SHOULD, or shallow hinge capability
  MEDIUM   — Shallow MUST-feature (works but thin)
  LOW      — Missing "nice to have" or cosmetic gap

EXAMPLE FINDING:
  [CRITICAL] PRD §3.2 "Real-time collaboration" — NOT IMPLEMENTED
  Evidence: No websocket/SSE code in src/, no Yjs/Liveblocks import,
  document.tsx uses local state only. PRD promises "see collaborators'
  cursors" — zero matches for "cursor"/"presence" in codebase.
  Impact: Core selling point on landing page is a lie.
  Fix: Integrate Liveblocks or Yjs, add presence layer, cursor overlay.

OUTPUT: Feature compliance matrix (feature × evidence × score × severity)
```

---

## PHASE 2: FEATURE DEPTH SCORING

> *"A feature isn't done when it works. It's done when it works for everyone, everywhere, every time."*

```
FOR EACH implemented feature, score DEPTH across 5 dimensions (0-10 each):

1. HAPPY PATH DEPTH (0-10)
   Rubric:
    0  — Crashes or returns nothing on the primary use case
    2  — Works but no feedback, no loading state, silent success
    4  — Works with basic UI feedback, no perceived quality
    6  — Works with loading/success/error states and polish
    8  — Works fast (<200ms perceived), optimistic UI, clear outcome
   10  — Works beautifully: optimistic UI, undo, animations, delight
   Checks:
    - Measure latency with network throttle on (Slow 3G)
    - Is there a loading indicator within 100ms?
    - Is success confirmed visually AND textually?
    - Is the user's next logical action suggested?

2. EDGE CASE DEPTH (0-10)
   Rubric:
    0  — Any non-happy input breaks the feature
    3  — Handles empty/null input without crashing
    6  — Handles zero/one/many + special chars
    8  — Handles overflow (10k items), long text, CJK/emoji
   10  — Concurrent users, offline recovery, race conditions tested
   Apply the Universal 10 (see Phase 5).

3. ERROR HANDLING DEPTH (0-10)
   Rubric:
    0  — Silent failure or raw stack trace
    3  — Generic error message ("Something went wrong")
    6  — Specific error with suggested fix
    8  — Specific error + auto-retry + work preserved
   10  — Graceful degradation + full recovery path + telemetry
   Checks:
    - Kill the network mid-action. What happens?
    - Send 401 / 403 / 429 / 500 from API. Each rendered clearly?
    - Is user input preserved on error (no data loss)?
    - Is there a "retry" affordance?

4. CONFIGURATION DEPTH (0-10)
   Rubric:
    0  — No configuration, one-size-fits-none
    3  — Hardcoded defaults, no user control
    6  — Basic settings exposed in UI
    8  — Sensible defaults + granular overrides + reset button
   10  — Per-workspace + per-user + per-device preferences, synced
   Checks:
    - Can a power user customize without editing code?
    - Are defaults good enough that 80% of users never touch settings?
    - Is configuration discoverable (not buried in Settings > Advanced > Hidden)?

5. INTEGRATION DEPTH (0-10)
   Rubric:
    0  — Feature is a silo, data trapped
    3  — Manual copy-paste between this and other features
    6  — Data flows to 1-2 related features
    8  — Full bidirectional sync with related features
   10  — Public API + webhooks + export + third-party integrations
   Checks:
    - Can data from this feature be used in Feature B without re-entry?
    - Is there an export (CSV/JSON/PDF)?
    - Is there an API endpoint for this feature?
    - Do webhooks fire on key events?

TOTAL DEPTH per feature: /50
GRADING:
  45-50 — SHIP-READY (deep feature)
  35-44 — USABLE (core works, corners rough)
  25-34 — SHALLOW (happy path only)
  15-24 — DEMO-WARE (looks good, falls apart on use)
   0-14 — BROKEN PROMISE
```

---

## PHASE 3: FEATURE DISCOVERABILITY

> *"A feature nobody finds is a feature nobody uses."*

```
FOR EACH feature:

1. NAVIGATION PATH
   → How many clicks from the main page to reach it?
   → Is it in the primary navigation? Secondary? Hidden in settings?
   → Does the label clearly describe what it does?

2. PROGRESSIVE DISCLOSURE
   → Do advanced features appear only when needed?
   → Are basic features immediately visible?
   → Is there a clear hierarchy: essential → useful → advanced?

3. ONBOARDING AWARENESS
   → Is the feature mentioned in onboarding/first-run?
   → Are there tooltips or contextual help?
   → Would a new user know this feature exists?

4. SEARCH/COMMAND ACCESS
   → Can the feature be found via search? (cmd+k, search bar)
   → Are there keyboard shortcuts?
   → Is it mentioned in help/docs?
```

---

## PHASE 4: FEATURE COHERENCE

> *"Features that don't talk to each other aren't features. They're silos."*

```
1. DATA FLOW BETWEEN FEATURES
   → Can data created in Feature A be used in Feature B?
   → Is there copy-paste between features? (should be integrated instead)
   → Are there duplicate data entry points? (same info entered twice)

2. PATTERN CONSISTENCY
   → Do similar features work the same way? (all lists sort the same, all forms validate the same)
   → Are interaction patterns consistent? (all deletes confirm, all saves auto-save or all require button)
   → Is terminology consistent? (not "project" here and "workspace" there)

3. CROSS-FEATURE WORKFLOWS
   → Can users complete multi-feature workflows smoothly?
   → Are there handoff points between features? (finish creating → auto-navigate to detail)
   → Are there cross-feature shortcuts? (from invoice → go to customer → go to project)
```

---

## PHASE 5: EDGE CASE COMPLETENESS

> *"The feature works with 3 items. What about 0? 1? 10,000?"*

```
THE UNIVERSAL 10 EDGE CASE CHECKLIST (apply to every feature):

 1. ZERO STATE — No data yet.
    - Is there an empty state component? Or just a blank screen?
    - Does it teach the user what to do next? (CTA present?)
    - Does it crash on map/length/filter of undefined?
    Pattern grep: `\.map\(` / `\.length` without `?.` or null check

 2. ONE STATE — Single item.
    - Layout correct? Singular "1 item" (not "1 items")?
    - Pagination hidden? Or showing "1-1 of 1"?
    - Actions apply? (can you delete the only item?)

 3. FEW STATE — 3-5 items. Normal operation baseline.

 4. MANY STATE — 100+ items.
    - Pagination, virtual scroll, or lazy load present?
    - Does the page freeze? (measure TTI with 100 items)
    - Sort/filter still fast? (<500ms)

 5. OVERFLOW — 10,000+ items.
    - Does the browser OOM?
    - Is there a hard cap? Is it communicated?
    - DB query plan — indexed? or full scan?

 6. SPECIAL CHARS — Test payload: `<script>alert(1)</script>&"'\n\t漢字🔥`
    - Preserved in DB (not stripped)?
    - Rendered safely (not XSS)?
    - Searchable (CJK full-text)?
    - CSV export escapes correctly?

 7. LONG TEXT — 10,000+ character input.
    - Truncated in list view with "..."?
    - Full text accessible in detail view?
    - No layout break (overflow: hidden or word-break)?
    - Does the API reject with clear 413? Or accept silently then crash?

 8. CONCURRENT — Two users, same feature, same second.
    - Optimistic locking? Version field? Last-write-wins?
    - Merge conflict UI? Or silent overwrite?
    - Websocket updates propagate?

 9. MOBILE — Same feature on phone (375×667 viewport).
    - Touch targets ≥44×44px?
    - Modals/drawers full-screen on mobile?
    - Hover states have touch equivalents?
    - Keyboard doesn't cover input field?

10. OFFLINE — Network drops mid-feature (DevTools → Offline).
    - Is there an offline indicator?
    - Are writes queued? Or lost?
    - On reconnect: auto-retry or manual?
    - No infinite spinner (timeout after 10s)?

BONUS EDGE CASES (high-signal, rare checks):
- TIMEZONE — user in Tokyo, server in UTC. Dates correct?
- LOCALE — numbers "1.234,56" vs "1,234.56" — parsed correctly?
- CLOCK SKEW — client time 5 minutes off. JWT expiry respected?
- TAB RESTORE — browser restart, session intact?
- BACK BUTTON — mid-flow back. State preserved or broken?

SEVERITY:
  CRITICAL — Crashes, data loss, security (XSS, injection)
  HIGH     — Functionally broken (zero state blank, overflow freezes)
  MEDIUM   — UX bug (pluralization, truncation missing)
  LOW      — Polish (empty state not illustrated)

EXAMPLE FINDING:
  [HIGH] /projects page — Zero state is blank white screen
  Evidence: src/app/projects/page.tsx line 34:
    `return projects.map(p => <ProjectCard />)`
  No guard for `projects.length === 0`. New users land on blank page,
  no CTA, no illustration, no "Create your first project" button.
  Fix: Add <EmptyState> component with CTA before the map.
```

---

## PHASE 6: API SURFACE COMPLETENESS

> *"If it's not in the API, it doesn't exist for power users."*

```
1. CRUD COVERAGE
   FOR EACH entity:
   → Create endpoint exists?
   → Read (single + list) endpoints exist?
   → Update endpoint exists?
   → Delete endpoint exists?
   → Any CRUD operations missing?

2. QUERY CAPABILITIES
   → Filter by each field? Or only some?
   → Sort by each field? Or only some?
   → Pagination? Cursor or offset?
   → Full-text search?
   → Date range queries?

3. BULK OPERATIONS
   → Bulk create? Bulk update? Bulk delete?
   → Import/export via API?
   → Rate limits documented?

4. WEBHOOK/EVENT COVERAGE
   → Events emitted for each CRUD operation?
   → Can external systems react to changes?
```

---

## PHASE 7: COMPETITIVE PARITY ANALYSIS

> *"Your users came from somewhere. They expect what they had."*

```
1. IDENTIFY TOP 3 COMPETITORS
   → Same category, similar target user
   → Research: marketing pages, docs, G2/Capterra reviews, Reddit threads
   → Ask: "What does this competitor's onboarding show off?"

2. FEATURE MATRIX
   | Feature              | Us  | Comp 1 | Comp 2 | Comp 3 | Classification |
   | Dark mode            | YES | YES    | YES    | YES    | TABLE STAKES   |
   | Export to PDF        | NO  | YES    | YES    | YES    | TABLE STAKES ← GAP |
   | Team workspaces      | YES | YES    | NO     | YES    | MAJORITY       |
   | AI summary           | YES | NO     | NO     | NO     | DIFFERENTIATOR |
   Mark each: YES / PARTIAL / NO / BETTER

3. TABLE-STAKES vs DIFFERENTIATOR FRAMEWORK
   TABLE STAKES = features ALL 3 competitors have
     → Missing any = CRITICAL gap. Users will churn.
     → These are NOT features. They are expectations.
     → Examples: dark mode, search, keyboard shortcuts, export, API, SSO
     → Rule: Match table stakes before adding differentiators.

   MAJORITY = features 2 of 3 competitors have
     → Missing = HIGH gap. Users will notice.
     → Acceptable to skip if explicit strategic decision.

   MINORITY = features 1 of 3 competitors have
     → Optional. Build if it fits hinge capability.

   DIFFERENTIATORS = features ONLY you have
     → Must be prominent in marketing (hero section, onboarding)
     → If hidden, differentiator is wasted
     → Rule: Every differentiator gets 3x the UI real estate

4. SWITCHING COST AUDIT
   → Can users import from each competitor? (CSV, API, OAuth)
   → Is there a "switch from X" landing page?
   → Does the UI use vocabulary familiar to switchers?

5. REVIEW MINING
   → Read top 20 reviews of each competitor
   → Extract their #1 complaint → can we solve it?
   → Extract their #1 praise → do we match or beat it?

SEVERITY:
  CRITICAL — Missing table-stakes feature
  HIGH     — Missing majority feature OR differentiator hidden from UI
  MEDIUM   — Feature matches competitor but UX is worse
  LOW      — Missing minority feature with no user demand signal

EXAMPLE FINDING:
  [CRITICAL] No "Export to PDF" — all 3 competitors have it
  Evidence: Notion, Coda, Craft all have one-click PDF export.
  Our /documents page has no export menu at all.
  Impact: Enterprise evaluators will fail this on checklist day 1.
  Fix: Add export-to-pdf action via react-pdf or Puppeteer route.
```

---

## PHASE 8: EMPTY IMPLEMENTATION DETECTION

> *"A button that does nothing is worse than no button at all."*

```
SPECIFIC GREP PATTERNS (run each):

1. STUB ROUTES & PLACEHOLDERS
   grep -rn "coming soon\|Coming Soon\|COMING_SOON" src/
   grep -rn "TODO\|FIXME\|XXX\|HACK\|WIP" src/ --include="*.tsx" --include="*.ts"
   grep -rn "not implemented\|not yet\|placeholder" src/ -i
   grep -rn "return null" src/app/ --include="page.tsx"
   grep -rn "<div />\|<></>" src/app/ --include="page.tsx"

2. NO-OP HANDLERS
   grep -rn "onClick={() => {}}" src/
   grep -rn "onClick={() => console" src/
   grep -rn "onSubmit={() => {}}" src/
   grep -rn "// TODO: implement" src/
   Regex: `on[A-Z]\w+=\{?\(\s*\)\s*=>\s*\{?\s*\}?\s*\}?`
   API: grep for "return new Response" where body is empty/mock
   API: grep for "return NextResponse.json({})"

3. PARTIAL CRUD DETECTION
   For each entity/route group:
     - Does `POST` exist? (Create)
     - Does `GET` (list + single) exist? (Read)
     - Does `PATCH`/`PUT` exist? (Update)
     - Does `DELETE` exist? (Delete)
   Missing any = partial CRUD = HIGH severity

4. PARTIAL EXPORT/IMPORT
   - If export exists, does it support >1 format?
   - If import exists, does it mirror export formats?
   - Bulk operations: create/update/delete in bulk?

5. PARTIAL SEARCH/FILTER
   grep -rn "search" src/app/api/ → count search fields queried
   If search only matches 1 field when entity has 10, that's partial
   Filter with only 1 option = probably incomplete

6. FEATURE FLAG GRAVEYARD
   grep -rn "featureFlag\|FEATURE_\|isEnabled\|flags\." src/
   For each flag: is it ever set to true in any env?
   Code gated by permanently-false flag = DEAD CODE

7. UNREACHABLE UI CODE
   - Pages that exist in src/app/ but no nav link points to them
   - Components exported but never imported
   - API endpoints called from nothing (grep for route string in src/)

8. MOCK DATA LEFT IN PROD
   grep -rn "mockData\|fakeData\|dummyData\|lorem ipsum" src/
   grep -rn "MOCK_\|FAKE_\|TEST_DATA" src/
   grep -rn "hardcoded\|HARDCODED" src/

SEVERITY:
  CRITICAL — Handler returns success but persists nothing (data loss)
  HIGH     — Visible UI element that does nothing on click
  MEDIUM   — Partial CRUD (missing delete, missing update)
  LOW      — TODO comment in non-user-facing code

EXAMPLE FINDING:
  [CRITICAL] POST /api/invite silently drops invites
  Evidence: src/app/api/invite/route.ts line 12:
    `export async function POST() { return NextResponse.json({ ok: true }) }`
  No DB write, no email send, no queue push. Returns 200 OK.
  User sees "Invite sent!" toast. Invitee never hears anything.
  Fix: Persist to `invites` table, enqueue email via Resend, return invite ID.
```

---

## PHASE 9: CONFIGURATION GAPS

```
Settings that SHOULD exist but don't:
  - Notification preferences (email/push/in-app toggles per event)
  - Default view (list vs grid, sort order, filter presets)
  - Timezone + locale + date format
  - Theme (light/dark/system)
  - Keyboard shortcuts override
  - Per-workspace defaults
  - Data retention period
  - Export format default

CHECKS:
  - grep Settings page → count exposed options
  - Compare against competitor settings pages
  - Every hardcoded constant in code = potential missing setting

SEVERITY:
  HIGH   — Missing notification controls (users can't opt out of noise)
  MEDIUM — Missing theme/locale (users expect these in 2026)
  LOW    — Missing power-user configs
```

## PHASE 10: DOCUMENTATION GAPS

```
For each feature, check:
  - Tooltip on hover? (<Tooltip> present?)
  - Help link in context? ("Learn more →")
  - Documentation page exists?
  - Empty state explains what the feature does?
  - Keyboard shortcut discoverable? (Cmd+/ menu)
  - API endpoint documented? (OpenAPI/Swagger?)
  - Changelog entries for new features?

CHECKS:
  - grep for <Tooltip|title=|aria-label on interactive elements
  - Count docs pages vs count features. Ratio?
  - New user test: can they use Feature X with zero external help?

SEVERITY:
  HIGH   — Hinge feature has zero docs or tooltips
  MEDIUM — Feature buried with no onboarding mention
  LOW    — Nice-to-have feature missing tooltip
```

## PHASE 11: PERMISSION MATRIX COMPLETENESS

```
Build the RBAC matrix:
  | Action | Owner | Admin | Member | Viewer | Guest |
  | Create project | Y | Y | Y | N | N |
  ...
  For EACH entity × EACH operation × EACH role → is it enforced?

CHECKS:
  - grep "role ===" or "permissions.includes" in API routes
  - For each destructive operation: is it restricted?
  - For each billing operation: is it Owner-only?
  - Is there a "share with read-only" option?
  - Can admins delegate without becoming owners?

SEVERITY:
  CRITICAL — Missing permission check (anyone can delete anything)
  HIGH     — Over-permissive defaults (new members get full access)
  MEDIUM   — Missing role tier (only 2 roles when product needs 4)
  LOW      — Role labels unclear ("User" vs "Member")
```

## PHASE 12: DATA MODEL GAPS

```
Schema gaps to check:
  - Entities missing fields users expect (e.g., Task without dueDate)
  - Missing soft-delete (deletedAt column)
  - Missing audit trail (createdBy, updatedBy, updatedAt)
  - Missing version field (optimistic locking)
  - Missing tenancy field (workspaceId on every row)
  - Foreign keys that should cascade but don't
  - Indexes missing on common filter fields
  - Enum fields that should be lookup tables

CHECKS:
  - Read schema.prisma / convex/schema.ts / migrations
  - For each entity: ownership, timestamps, soft-delete, versioning
  - Compare to competitor's data model (often inferable from API)

SEVERITY:
  CRITICAL — Missing tenancy (multi-tenant data leak risk)
  HIGH     — Missing audit trail (can't debug user reports)
  MEDIUM   — Missing soft-delete (accidental permanent deletion)
  LOW      — Missing indexes (slow but working)
```

## PHASE 13: INTEGRATION GAPS

```
Third-party connections users expect:
  - Auth: Google, Apple, Microsoft, GitHub, SSO/SAML
  - Payments: Stripe, Paddle, LemonSqueezy
  - Email: Resend, Postmark, SendGrid
  - Analytics: PostHog, Mixpanel, Plausible
  - Storage: S3, R2, Cloudinary, UploadThing
  - Comms: Slack, Discord, Teams, email digest
  - Data: CSV import/export, Zapier, webhooks, public API
  - Calendar: Google Cal, Outlook, ICS feed

CHECKS:
  - Settings → Integrations page exists?
  - For each "table stakes" integration in the category: present?
  - Webhook configuration UI?
  - OAuth app credentials documented for self-hosters?

SEVERITY:
  HIGH   — Missing SSO for B2B product (enterprise dealbreaker)
  MEDIUM — Missing Zapier/webhook (power users can't extend)
  LOW    — Missing niche integration
```

## PHASE 14: SCALING READINESS

```
Features that work now but won't at 10x/100x:
  - Lists without pagination (breaks at 1k+ rows)
  - Full-table scans (no indexes on filter fields)
  - Client-side sort/filter on 10k items (freezes UI)
  - Unbounded file uploads (no size limit, no scanning)
  - Unbounded query parameters (no LIMIT clause)
  - Sync operations that should be async (email send in request thread)
  - No rate limiting (easy to DoS or run up costs)
  - No caching layer (every page re-renders from DB)
  - Single-region deployment when users are global

CHECKS:
  - Load test feature with 10k records
  - Review DB query plans for full scans
  - Check background job queue presence
  - Check rate limit middleware

SEVERITY:
  CRITICAL — Core feature freezes at realistic scale
  HIGH     — No rate limiting on expensive endpoints
  MEDIUM   — Missing pagination (works but loads slowly)
  LOW      — Missing caching (fast enough for now)
```

## PHASE 15: ACCESSIBILITY FEATURES (per-feature a11y)

```
For each feature, verify:
  - Keyboard-only reachable?
  - Screen reader announces state changes?
  - Color not the only signal?
  - Focus trap in modals?
  - Skip links for long lists?
  - prefers-reduced-motion respected?
  - Error messages linked to fields (aria-describedby)?

NOTE: /a11yaudit does a deep dive. Here we check if each FEATURE has
a11y coverage, not the pixel-level WCAG checks.

SEVERITY:
  HIGH   — Hinge feature is keyboard-unreachable
  MEDIUM — Feature works but screen readers silent
  LOW    — Motion not reduced for users who opt out
```

## PHASE 16: FEATURE ENTROPY (naming + pattern consistency)

```
Inconsistencies across features:
  - Terminology drift: "project" vs "workspace" vs "board" vs "space"
  - Verb drift: "delete" vs "remove" vs "archive" vs "trash"
  - Same concept, different UI: some lists sort in place, others paginate
  - Confirmation pattern drift: some deletes confirm, others don't
  - Save pattern drift: some auto-save, some need explicit button
  - Modal vs drawer vs route for the same type of flow
  - Icon drift: + icon means "add" here, "expand" there
  - Date format drift: "Jan 1, 2026" here, "2026-01-01" there
  - Empty state drift: illustrated here, blank there

CHECKS:
  - Build a glossary of terms from UI strings
  - Flag synonyms (project=workspace=board)
  - Screenshot each list → compare sort/filter/pagination controls
  - Screenshot each destructive action → compare confirm patterns

SEVERITY:
  HIGH   — Same entity named differently in 2+ places (users confused)
  MEDIUM — Inconsistent interaction patterns for similar actions
  LOW    — Cosmetic icon/label inconsistency
```

---

## PHASE 17: VERDICT

```
SCORING MATRIX (320 max):
  Phase  1  (PRD Compliance)       × 3.0  = max 30
  Phase  2  (Feature Depth)        × 3.0  = max 30
  Phase  3  (Discoverability)      × 2.0  = max 20
  Phase  4  (Coherence)            × 2.5  = max 25
  Phase  5  (Edge Cases)           × 2.5  = max 25
  Phase  6  (API Surface)          × 2.0  = max 20
  Phase  7  (Competitive Parity)   × 2.5  = max 25
  Phase  8  (Empty Implementations)× 3.0  = max 30
  Phase  9  (Configuration)        × 1.5  = max 15
  Phase 10  (Documentation)        × 1.5  = max 15
  Phase 11  (Permissions)          × 2.0  = max 20
  Phase 12  (Data Model)           × 2.0  = max 20
  Phase 13  (Integrations)         × 1.5  = max 15
  Phase 14  (Scaling)              × 1.5  = max 15
  Phase 15  (Accessibility)        × 1.5  = max 15
  Phase 16  (Entropy)              × 1.0  = max 10
                                   TOTAL  = max 320 (excl N/A)

NORMALIZE: score = (raw / applicable_max) × 100

GRADE:
  90-100: S — Complete. Production-ready, nothing missing.
  80-89:  A — Solid. Minor gaps, all core features deep.
  70-79:  B — Good. Some features shallow, most present.
  60-69:  C — Gaps. Notable missing features or stubs.
  50-59:  D — Incomplete. Major features missing or shallow.
  <50:    F — MVP at best. Significant work remaining.
```

---

## PHASE 18-20: FIX PLAN → IMPLEMENTATION → RE-AUDIT

```
Phase 18: Generate prioritized implementation plan
  → CRITICAL: missing core features, empty implementations
  → HIGH: shallow features needing depth
  → MEDIUM: missing edge cases, config, docs
  → LOW: competitive nice-to-haves, polish

Phase 19: Implementation (spawn agents)

  ─── SAFETY GATE: DO NO HARM (MANDATORY before EVERY fix) ──────────────

  The audit MUST NOT introduce new bugs. A fix that breaks the code is worse than
  the original finding. Every fix goes through this gate BEFORE commit.

  PRE-FIX ANALYSIS (before writing ANY code):
    a. Read the ENTIRE target file (not just the target line)
    b. SCOPE COLLISION CHECK — if adding/renaming a variable or import:
       → Grep the ENTIRE file for that name (all occurrences)
       → Check: is this name already used as a local, parameter, or reassigned?
       → Check: does this name get shadowed later in the same scope?
       → If collision found → use a different name or fully-qualified reference
    c. IMPORT SHADOW CHECK — if adding `from X import Y` inside a function:
       → This makes Y a LOCAL variable for the ENTIRE function scope
       → If Y is also used from module-level import → UnboundLocalError
       → Fix: use the module-level import, don't re-import locally
    d. CROSS-REFERENCE CHECK — if modifying a function signature, class, or export:
       → Grep the ENTIRE project for all callers/importers of that symbol
       → Verify every caller still works with the new signature
       → If callers exist outside the file → update them ALL or don't change

  POST-FIX VERIFICATION (after writing code, BEFORE commit):
    a. SYNTAX CHECK:
       → Python: `python -c "import ast; ast.parse(open('FILE').read())"`
       → JS/TS: `npx tsc --noEmit` or `node -c FILE`
    b. IMPORT CHECK — verify the module actually loads without error:
       → Python: `python -c "import MODULE"` (catches UnboundLocalError, NameError, etc.)
       → JS: `node -e "require('./FILE')"`
    c. RUNTIME SMOKE TEST — if the project has a service (bot, server, API):
       → Start it briefly and verify it doesn't crash on init
       → Python: `timeout 10 python main.py` or systemctl restart + is-active check
       → Node: `timeout 10 node server.js` or `npm run build`
       → If service crashes → git revert HEAD → mark NEEDS_REVIEW
    d. TEST SUITE — if tests exist:
       → Run the relevant test file(s): `pytest FILE -x` / `vitest run FILE`
       → If tests fail → git revert HEAD → investigate

  IF ANY POST-FIX CHECK FAILS:
    → `git revert HEAD` immediately
    → Log the failure in audits/.featureaudit/fix-log.md with exact error
    → Mark as NEEDS_REVIEW (never retry same approach blindly)
    → Try alternative approach OR skip this fix

  ────────────────────────────────────────────────────────────────────────

  FOR EACH implementation task:
    a. Read the ENTIRE target file (full context)
    b. Run PRE-FIX ANALYSIS (scope collision, import shadow, cross-reference)
    c. Implement the feature/depth
    d. Run POST-FIX VERIFICATION (syntax, import, smoke test, tests)
    e. If all green → commit
    f. If any red → revert → log → mark NEEDS_REVIEW

Phase 20: Re-audit
  1. SERVICE HEALTH GATE (mandatory):
     → If project has systemd service: restart it, wait 10s, check is-active + logs for errors
     → If project has build step: full build must pass
     → If project has tests: full test suite must pass
     → If ANY fails: identify which fix broke it, revert
  2. Re-run failing phases, compare scores
  3. Loop until score >= 80
```

---

## CROSS-COMMAND BRIDGE

```
THE QUALITY QUINTFECTA:
  /codeaudit    → Is the CODE solid?           (preventive, static)
  /flowaudit    → Does the EXPERIENCE work?     (preventive, logical)
  /uiuxaudit    → Is the INTERFACE beautiful?   (preventive, visual)
  /debugaudit   → What is BROKEN right now?     (detective, runtime)
  /featureaudit → Is the product COMPLETE?       (strategic, gaps)

  Together: Code × Flow × Design × Runtime × Completeness = Ship-Ready.

  /featureaudit finds missing features → implements them
  /featureaudit finds shallow features → deepens them
  /featureaudit finds stubs → completes or removes them
```

---

## LAWS

1. **Missing is worse than broken.** A broken feature can be fixed. A missing feature means users leave.
2. **Shallow is a lie.** "We have search" means users expect search to WORK. A search bar that searches one field is a lie.
3. **The PRD is a promise.** Every unpromised feature is a bonus. Every promised but missing feature is a betrayal.
4. **Competitors set expectations.** Users don't evaluate your product in isolation. They compare.
5. **Edge cases are not edge cases.** They're the experience of your most engaged users.
6. **Empty states are first impressions.** The zero-data experience IS the onboarding.
7. **The product is incomplete until proven complete (Popper).** Default verdict: NOT READY.

---

*"/featureaudit v1 — Inventory. Score. Gap. Build. Every feature, every depth, every competitor. /320."*

---

## COMPLIANCE & CRITICAL ADDENDA (v1.1 — 2026-04-14T10:35:36Z)

### Quality Arsenal Preamble Compliance

This audit implements contracts defined in `../_shared/QUALITY-ARSENAL-PREAMBLE.md` v1.0:

- ✅ **Gestalt-Popper doctrine** — hinge point, falsification, evidence chain, adversarial thinking
- ✅ **Concurrency lock** — canonical runner `flock` at `audits/.featureaudit/.runner.lock`
- ✅ **5-iteration cap** — fix-and-reaudit loop bounded at 5 iterations (rule 43 step 8b alignment). On cap: NEEDS_REVIEW + Telegram SOS. No silent infinite loops.
- ✅ **Scoped invocation flags** — `--url=`, `--files=`, `--scope=`, `--ticket=`, `--no-fix`, `--focus=`
- ✅ **Non-UI context gate** — Non-UI contexts: feature audit works on any project type (library features, CLI features, API features all valid).
- ✅ **Output contract verification** — emits `audits/.featureaudit/verdict.json`, `verdict.md`, `fix-plan.json`, `fix-plan.md`, `iterations.md`, `progress.json`, `telemetry.json`, `fix-log.md`. Output gate runs at end; missing/malformed files = audit did NOT succeed.
- ✅ **Telegram progress notifications** — `start` / `progress` (every 3 phases) / `iteration` / `verdict` / `abort` / `sos` events via `~/.omega/bin/audit-notify.sh`
- ✅ **Discovery drift check** — on resumed runs, if `audits/.featureaudit/discovery/` > 1h old, re-verify inventory or abort with user-confirm
- ✅ **Self-telemetry** — `audits/.featureaudit/telemetry.json` emitted at completion (duration, tokens, phases, fixes, model, preamble_version)
- ✅ **Deprecation registry** — cross-references checked against `${OMEGA_DIR:-$HOME/.omega}/skills/audits/_shared/DEPRECATED.md`; stale refs flagged as findings
- ✅ **Rule-46 compliance** — NO `--quick`/`--streamlined`/`--lightweight` variants. Narrower scope uses `--focus <area>` flags with FULL phase depth. Orchestrator prompts containing rule-46 banned phrases are REFUSED.
- ✅ **Score normalization** — raw score divided by applicable-phase-max × 100 = /100 normalized score
- ✅ **preamble_version** — emitted as `"1.0"` in verdict.json for `/metaudit` compliance scan

### Audit-Specific Critical Addendum — No-PRD Fallback + WebSearch Budget

No PRD exists? Generate an **implicit PRD** from:
1. `README.md` features section (grep `## Features|## What`)
2. `package.json` description + keywords
3. Routes/pages discovered via Glob on `src/app/**/page.{tsx,jsx}`, `pages/**`
4. Convex schema (if present) — entity → feature inference
5. API endpoints (if present) — endpoint → feature inference

Label each finding as "inferred-PRD" vs "explicit-PRD" — confidence differs.

**WebSearch budget (per preamble §9 telemetry):**
- Max 10 queries per audit (competitive parity research)
- Emit `websearch_count` + `websearch_queries[]` in telemetry.json
- Abort phase 12 (parity check) if quota exceeded; do not degrade to zero.

### Scoring addenda

Normalized score = (raw_score / applicable_raw_max) × 100.
Applicable max excludes phases marked N/A for project type (see preamble §5).
`verdict.json.preamble_version = "1.0"` is MANDATORY. Missing field = /metaudit flags as non-compliant.

### /metaudit Compliance Badge

Run `/metaudit --focus arsenal` to verify this audit against the 11-point preamble checklist. Target score: 11/11.

---

*v1.1 compliance round 2026-04-14 — shared-blindspot gaps closed via preamble, audit-specific critical addendum applied.*

---

## § 100/100 COMPLIANCE CERTIFICATE — v1.2 — 2026-04-14T10:43:29Z

> *Final gap-closure layer. Every finding from the prior /flowaudit-of-all-audits analysis (featureaudit-specific section) is now explicitly resolved below.*

### Compliance Matrix (machine-verifiable by /metaudit)

```json
{
  "audit": "featureaudit",
  "preamble_version": "1.0",
  "compliance_version": "1.2",
  "compliance_score": 100,
  "shared_blindspots_closed": {
    "S1_concurrency_lock": true,
    "S2_reaudit_cap_5_iter": true,
    "S3_non_ui_context_handling": true,
    "S4_telegram_progress": true,
    "S5_scoped_invocation_flags": true,
    "S6_output_contract_verification": true,
    "S7_self_telemetry": true,
    "S8_phase_count_rationale_documented": true,
    "S9_discovery_drift_check": true,
    "S10_deprecation_registry_reference": true
  },
  "audit_specific_gaps_closed": true,
  "rule_46_com

…(truncated)