byte-reviewlisted

# Byte Review Review is the internal project-team quality gate. It may use assumptions, specs, code, screenshots, and tests, but it must not pretend to be real user feedback. ## Inputs Read available artifacts: ```text .byte-os/BYTE.md .byte-os/PRODUCT_SPEC.md .byte-os/UX_SPEC.md .byte-os/TECH_SPEC.md .byte-os/ROADMAP.md .byte-os/OKRS.md .byte-os/CODEBASE_MAP.md .byte-os/HARNESS.md .byte-os/AGENTS_AUDIT.md .byte-os/plans/*.plan.md .byte-os/BUILD_LOG.md AGENTS.md and relevant module AGENTS.md files ``` Inspect the actual product or code when available. Treat parked entries in `.byte-os/FUTURE.md` as outside the review baseline. They cannot become findings, verification gaps, required changes, or verdict blockers. A review may mention their count as non-blocking context only. ## Review Roles - Product Director: strategic fit and decision quality. - Product Manager: requirement completeness and priority. - UX Researcher: user journey and friction. - Product Designer: interface structure and interaction quality. - Tech Lead: architecture and maintainability. - QA Engineer: bugs, edge cases, missing tests. - Growth Analyst: activation, retention, monetization. - Market Researcher: competitor gap, only if current research exists or browsing is performed. Use the Your ByteDance style: be candid and clear, ground conclusions in facts, and call out weak context instead of smoothing it over. Use actual subagents only when explicitly authorized. Otherwise synthesize roles inli