Customizable navigation drawer

The bet — easing access to Code/Dispatch for high-ARPU (Pro/Max) users to drive retention / reduce churn — is plausible but unproven, and the three success metrics (adoption, efficiency, config-retention) are all UX proxies. The make-or-break gate is a retention/renewal A/B (adopters vs. a matched control in the same cohort), which isn't designed yet; without it, "success" is adoption + speed, not money.

Flagged by: business-viability  ·  Investigate: Finance/data + PM — design and pre-register the retention/renewal A/B (90-day churn/renewal delta, adopters vs. matched control) as the build gate; don't let UX-adoption proxies stand in for it.

In the prototype, drag has zero keyboard/screen-reader/switch route, and every edit action rebuilds the DOM and drops focus — breaking even the buttons that work. The spec calls the a11y actions "mandatory" but underspecifies focus retention, a sighted-keyboard path, and locked-anchor interaction, so the mandatory path is at risk of being dropped.

Flagged by: accessibility, product-designer, tech-architect, legal-compliance  ·  Investigate: Accessibility + mobile eng — build and manually test a real TalkBack/switch/keyboard reorder path (WS-A11Y), re-architect the render to preserve focus, release-gated; designer adds the missing mechanics to the spec.

Nothing lets support view or reset a user's nav_preferences, so a "my menu changed / item disappeared" ticket that in-app Reset/"More" can't fix means diagnosing blind, with an ad-hoc eng DB edit the only escalation. Ownership of the cohort/telemetry pipeline and post-launch monitoring is also unnamed.

Flagged by: operational-readiness (privacy-security + ethics note the same gap)  ·  Investigate: Support lead + backend eng — scope a minimal read-and-reset support tool and name a pipeline owner before Phase 1 GA.

C2 caps the exposure loss from hiding Code/Dispatch/Artifacts at ~10%, and the open "More collapsed vs. expanded-by-default" question frames the business-favoring option as keeping the "hidden" item visible. Resolved toward the metric, "hide" is named as concealment but engineered not to conceal for the monetized surfaces (DSA Art. 25 / FTC §5 exposure) — and the veto sits with the feature team, not an independent growth owner.

Flagged by: ethics-trust-safety, business-viability, legal-compliance, product-analyst, product-manager (5)  ·  Investigate: Product leadership + design-ethics reviewer + independent growth owner — ratify that "hide" must functionally reduce exposure; resolve "More" in the user's favor; treat C2's 10% as a ceiling to justify, not a target.

R11 per-account, high-granularity drawer telemetry ships early, broadly, "unflagged or near-so" under Experiment 1 — before the feature and regardless of whether it ever ships — with no retention window, no aggregation, no confirmed opt-out link, and no purpose-limit on the derived cohort/hide-state signals. EU/UK ePrivacy (TTDSG/PECR) imposes a consent-for-device-access test separate from GDPR, and it's unknown whether the native app has that gate.

Flagged by: privacy-security, legal-compliance, ethics-trust-safety (3)  ·  Investigate: Privacy counsel + data-governance + analytics eng — before WS-INSTR reaches EU/UK, confirm consent basis, set a bounded raw-event retention (e.g., 60–90 days) with aggregation, and purpose-scope the cohort label.

R4 is "enforced in code, not data." Without server-side write validation, a modified/replayed client could write hidden:[new_chat] or a malformed order to the synced store and — via last-writer-wins across every device — durably reproduce the exact fleet-wide "stranded from chat" failure the feature designs against. The write and telemetry paths also need account-scoped authz (IDOR could corrupt other blob fields; injected events could poison the cohort and C1/C2/C3 gates).

Flagged by: privacy-security  ·  Investigate: Backend/platform + security eng — add server-side schema validation (manifest allowlist, reject new_chat, size/dedupe) and pen-test both endpoints for ID/session substitution before WS-MODEL/WS-INSTR ship.

The ~12–21 eng-week cross-platform build (~7–12 for the Android beta) serves a minority the team's own evidence calls no-moat, while the same paying segment has documented Dispatch/Code reliability bugs (#39549/#54973/#46391) — a more direct retention mechanism no one has compared against. As a "sideways" feature it's a canonical candidate to be built Android-only then orphaned, never reaching the parity (R8) the PRD says is required.

Flagged by: business-viability (competitive on no-moat)  ·  Investigate: Product leadership — before Phase 1, require a stated reason this beats reliability work on retention-dollars-per-eng-week, and decide committed-multi-quarter vs. bounded-experiment explicitly.

No direct organic demand was found in any reachable channel; the evidence is adjacent (Claude Code desktop GitHub #72126/#70104/#25974) plus the n=1 requester — and the cohort the premise rests on has never been measured because the per-item telemetry doesn't exist yet.

Flagged by: user-research, product-manager, tech-architect (3)  ·  Investigate: PM + data — run Experiment 1 (WS-INSTR, ~1 eng-week), confirm the cohort at scale (Gate 1), and pull Anthropic-side feedback corpora the tools couldn't reach.

Every token and edit affordance is eyeballed from two Android dark-mode screenshots and is net-new to Claude mobile (the app teaches no list-edit gesture). If the live app has a contradicting pattern or the real token export differs, it reads "almost right but foreign" — and the demo commits to free-drag where the PRD left the mechanism open.

Flagged by: design-language, product-designer, prototyper, product-analyst (4)  ·  Investigate: Product-designer/prototyper — validate against a live build + token export and the live nav taxonomy before hi-fi; treat the demo as one option.

Set-default-landing would change app-open behavior and degrade the majority's chat loop (product-analyst: high/high) and has no positive comparator precedent, triggering a kill-condition (competitive: high/med). V1 cuts it — which addresses the risk — but the demo still persists "Opens on launch" on Done and adds a second clay marker, contradicting the cut.

Flagged by: product-analyst, competitive, user-research, ethics, prototyper, business-viability (6)  ·  Investigate: PM — confirm the cut + three-part reopening bar hold; prototyper — strip the launch-flag persistence + clay marker from the demo before any stakeholder review.

0dp gap between the adjacent hide/grip controls (spec mandates ≥8dp) on the exact "don't fat-finger" loop the feature is for; text/secondary on surface/1 fails AA (~4.27:1); the locked padlock uses an undocumented token at ~2.99:1 (below the 3:1 floor); and the mandated grab cue, aria-live, and per-hide Undo are unimplemented.

Flagged by: accessibility, product-designer (2)  ·  Investigate: Prototyper/eng — add ≥8dp spacing, fix the contrast tokens, wire aria-live + Undo + a grip-brightening cue; usability-test on-device.

Sync conflicts and old-client writes against an evolving schema can drop a customization with no notification, trail, or recovery beyond redoing it — a long-offline device reconnecting reads as "my menu randomly reverted," near-undiagnosable. tech-spec §8 proposes only "document it."

Flagged by: operational-readiness (tech-architect edge cases)  ·  Investigate: Backend eng — decide whether a lightweight conflict signal is worth it vs. accepting silent LWW; support lead gets a diagnostic macro regardless.

Every future nav change (add/rename/deprecate) now requires merge-path QA against customized-user states in perpetuity, and R9/R11 cohort thresholds decay as the taxonomy shifts — but no owner, checklist, or budget line exists. This drawer recently gained Code and Dispatch, so "add a nav item" is not rare.

Flagged by: operational-readiness  ·  Investigate: Mobile eng lead — own a nav-taxonomy change checklist; PM + data — name a permanent owner for cohort-definition health before the feature exits beta.

A persistent "Edit menu" affordance on the one screen every user sees — to serve a minority — risks an IA/complexity tax on the majority chat segment and could breach C1 (±2%), which sits on the dominant Free→Pro conversion loop. Low-salience / cohort-only mitigations are unverified.

Flagged by: product-analyst, product-manager, product-designer, business-viability (4)  ·  Investigate: Product-designer + PM — A/B quiet-row-for-all vs. cohort-only display, with C1 as a hard release gate.

Settings-gated, opt-in customization sees structurally low uptake without active promotion (Word study: <5% change any setting; ~86% keep default notifications), and this app teaches no list-edit gesture — so a silently-shipped affordance likely under-delivers even for the target cohort.

Flagged by: user-research, product-manager, competitive (3)  ·  Investigate: Product-designer + PM — commit to active targeted discovery (R9 prompt) and run Experiment 2 vs. the ~15% ceiling (<5% = kill/rescope).

The design is validated only for Android-phone dark mode; iOS, light mode, and tablet/desktop (a persistent sidebar, not a drawer) are behaviorally different and unobserved, and R8 sync is only partially deliverable in the Android-only beta — so a user who customizes on Android sees no change elsewhere, which the PRD's own bar says reads as a regression.

Flagged by: design-language, prototyper, operational-readiness (3)  ·  Investigate: PM — confirm the single V1 target and get iOS/light/desktop captures; align messaging to actual Phase-1 capability ("Android-only in V1").

The two edit-mode entries are a low-salience row and an undisclosed long-press, and the only recovery is a ~4s auto-dismissing Undo + a low-salience "More" — so an elderly, motor-impaired, or distracted user can hit edit mode by accident, mis-tap hide, and be left with a "missing" item that aggregate C1/C3 gates won't catch. A hidden Code/Dispatch may also delay reaching a pending real-world agent approval if notifications don't deep-link.

Flagged by: ethics-trust-safety  ·  Investigate: Product-designer + accessibility — usability-test the long-press mis-tap chain with older/motor-impaired testers, consider a longer recovery path, and resolve deep-linking with a safety framing.

Starred is almost certainly a per-project content boolean, so nav prefs are a NEW subsystem — anyone estimating from "we already have Starred" under-prices it. And the synced-preferences store's extensibility is unconfirmed: if schema-locked/other-team-owned, WS-MODEL roughly doubles (1–2 → 3–5 eng-weeks) with a cross-team dependency.

Flagged by: tech-architect  ·  Investigate: Mobile/backend eng lead — confirm Starred's implementation and any existing reorderable component, and the store's extensibility/ownership, before freezing scope.

New R11 event types very likely require App Store Connect "App Privacy" and Google Play "Data Safety" updates, and the analytics vendor should be confirmed not to meet Apple's ATT "tracking" definition — store-policy filings independent of privacy law, with their own rejection/takedown risk.

Flagged by: legal-compliance  ·  Investigate: Mobile platform/privacy eng — update both filings and confirm no ATT trigger before the beta / Experiment 1 broad rollout.

The resting "More · N" badge and the cohort-only R9 hint card are visible without entering edit mode — a small new signal ("this account deprioritized N items" / "flagged as a power-user cohort") that today's fixed six-item drawer doesn't expose to a shoulder-surfer or screen-share.

Flagged by: privacy-security  ·  Investigate: Product-designer — confirm this tradeoff is acceptable (consistent with the drawer already showing Starred/Recents at rest).

The reorder/hide pattern is fully commodity outside AI assistants and cheap for any of the five closest competitors to copy once prioritized (ChatGPT's community has asked since Jan 2024, unshipped). Any first-mover edge is temporary, not durable.

Flagged by: competitive-researcher  ·  Investigate: PM — frame this as "closing an AI-assistant-category gap for a valuable minority," not innovation, when presenting to leadership.