> For the complete documentation index, see [llms.txt](https://t420.gitbook.io/t420/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://t420.gitbook.io/t420/claude-everything-10of10-final.md). # claude-everything-10of10-final ## FleetOS — Final Everything 10/10 Task List Paste this into a fresh Claude Code terminal session at the FleetOS repo root. *** You are working in the `ZBO19/FleetOS` repository. Read these first: 1. `docs/agent.md` 2. `docs/production-plan.md` 3. `docs/api-mcp-spec.md` 4. `docs/openapi.yaml` 5. `docs/claude-final-10of10-kickoff.md` 6. `docs/claude-screenshot-ui-punchlist.md` 7. `docs/claude-master-polish-10of10.md` Then inspect the actual code, actual routes, actual settings/admin surfaces, actual API/developer surfaces, actual docs pages, and the latest mobile/desktop screenshots before making any claims. ### Mission Push FleetOS to **10/10 product quality**, **10/10 UX/UI**, and **10/10 developer-platform credibility**. This is the final full-system polish and best-practice pass. The goal is not “good enough.” The goal is: * premium readability * premium usability * premium trust * premium product coherence * premium developer credibility * no fake maturity * no obvious rough edges The whole thing must feel like one intentional platform. *** ### Non-negotiables * Do not break the supplier ↔ fleet workflow. * Do not break the API or developer surfaces. * Do not leave docs or marketing claiming features the product does not actually support. * Do not redesign the FleetOS brand. * Do not introduce random visual styles. * Improve the existing design system: contrast, spacing, hierarchy, affordance, consistency. * Keep changes incremental and strongly typed. * Preserve architectural quality while polishing. * Mobile experience must feel intentional, not like desktop squeezed into a phone. * Developer experience must feel like a first-class product surface. *** ## PART 1 — GLOBAL PRODUCT AUDIT AND TRUTH ### 1. Do a full reality audit before polishing You must first inspect and verify: * landing page * supplier dashboard * fleet dashboard * add job modal * feedback modal * settings page * docs page * developer docs page * API handlers * API key/webhook flow * shadow layer integration * route handling and deep-linking #### Output required before deep polish Produce a concrete list of: * what is already strong * what still feels prototype-ish * what is still inconsistent * what is visually weak * what is functionally weak * what is documented but still under-expressed in the UI *** ### 2. Remove all product-story mismatches Fix any remaining mismatch between: * landing page claims * docs claims * developer docs claims * settings/admin UI * actual API implementation * actual workflow behavior #### Rule If a feature is partial, say so cleanly. If a feature is real, expose it clearly. Nothing should feel fake, hidden, or accidental. *** ## PART 2 — VISUAL SYSTEM / READABILITY / AFFORDANCE ### 3. Raise readability across the whole product There are still places where text is technically visible but not comfortably readable. #### Fix globally * brighten section labels * brighten field labels * brighten empty-state/status text * brighten secondary helper text * brighten footer/docs/support links if they are too dim * brighten placeholder text enough to be readable without making it look like entered text #### Examples to fix * DETAILS * COORDINATOR * SCHEDULE * BAY * TECH * VEHICLE * PARTS * Send Response * No photos attached * settings explanatory copy * marketing body copy in feature cards * footer support/help links * developer/settings descriptions #### Target * primary values = strongest * secondary labels = clearly readable * helper text = subdued but still readable * no muddy grey-on-dark text *** ### 4. Strengthen weak controls and state affordances Some controls/states still feel too faint. #### Fix * strengthen ghost button borders where needed * strengthen state boxes that currently look like placeholders * make low-emphasis controls still feel intentional * ensure dashed-outline buttons feel active when they are active #### Examples * vehicle Pending box * * Add Part button * some small outline buttons inside cards * feedback modal action hierarchy * settings secondary actions #### Target A user should instantly know: * this is interactive * this is a status * this is disabled * this is secondary but still available *** ### 5. Standardize visual tokens everywhere Audit and unify: * border color strength * divider opacity * heading sizes * section title sizes * secondary text colors * placeholder colors * ghost button treatment * CTA button treatment * corner radius usage * shadow/glow usage * badge style usage * spacing scale #### Target The same visual logic should apply across: * dashboard * modals * settings * homepage * docs * developer docs *** ## PART 3 — MOBILE EXPERIENCE: SUPPLIER + FLEET DASHBOARDS ### 6. Finish collapsed card polish For both supplier and fleet cards: * improve label/value rhythm * improve truncation handling for long fleet/supplier/location strings * make status, WO number, and urgency badge align cleanly * keep card CTA anchor (Respond, View Details, Review Quote) readable and intentional * reduce any remaining text heaviness * ensure budget / over-budget treatment is crisp and legible #### Target Collapsed cards should scan in under 2 seconds. *** ### 7. Finish expanded card polish For both supplier and fleet expanded cards: * maintain strong section rhythm * reduce visual fatigue * keep each section purposeful * keep separators subtle but clear * reduce any remaining “stack of boxes” feeling * ensure timeline, details, schedule, response, and action areas each feel distinct #### Target Expanded cards should feel organized, calm, and operational. *** ### 8. Finalize schedule block to 10/10 The schedule block is close but still needs absolute polish. #### Fix * keep labels readable * ensure select width/height consistency * ensure Pending in vehicle row is clearly visible and reads like a real state * ensure Add Part feels like a real secondary action, not a faded placeholder * ensure row spacing is calm and balanced * ensure status dots, labels, and control widths feel aligned * audit focus/keyboard/tap feedback * ensure no row feels accidentally weak #### Target This block should feel like a premium operations control panel. *** ### 9. Finalize response section hierarchy #### Fix * keep Send Response clearly primary * keep Decline clearly secondary * keep Request Vehicle Delivery clearly tertiary/contextual * ensure no redundant information is repeated if already present in the card header * refine spacing between helper text, inputs, attachment, CTA, and secondary actions * ensure placeholders are readable * ensure amount row feels balanced #### Specific rule If budget is already shown in header, do not over-emphasize it again inside the response block. *** ### 10. Fix floating control interference everywhere #### Fix * reduce floating add-job button dominance if still too loud * reduce chat/feedback button interference with content * improve safe-area positioning * avoid overlap with key CTAs, inputs, and lower-right content * ensure floating controls feel helpful, not intrusive #### Target Floating controls are discoverable but never visually annoying. *** ### 11. Equal polish for fleet-side screens Supplier-side screens have received the most attention. Fleet-side needs full parity. #### Fix fleet-specific surfaces * quote review states * photo-add states * Contact / Cancel Job action row * Ready for Pickup states * completion evidence sections * pending approval wording and action clarity * supplier detail readability #### Target Fleet-side UX should feel every bit as polished as supplier-side UX. *** ## PART 4 — MODALS / FORMS / INPUT SYSTEM ### 12. Make Add Job modal world-class This is one of the most important flows in the product. #### Fix * label contrast * placeholder contrast * section spacing * field spacing * Existing Fleet / New Fleet segmented control polish * priority pill polish * date field + icon alignment * more-options discoverability and styling * mobile modal scroll rhythm * close button balance and hit area * scan VIN affordance #### Target Creating a job should feel premium and low-friction on both mobile and desktop. *** ### 13. Make feedback modal match product quality The feedback modal is good but still needs a premium pass. #### Fix * label contrast * placeholder readability * segmented control polish * field spacing consistency * screenshot capture CTA polish * Cancel vs Submit hierarchy * close button treatment #### Target Feedback modal should feel native to the product, not like an extra form. *** ### 14. Standardize form behaviors everywhere Audit and unify across: * Add Job modal * feedback modal * settings * response panels * docs/admin control forms #### Standardize * input heights * label spacing * border radii * focus states * error states * disabled states * select arrow treatment * helper text spacing * CTA alignment *** ## PART 5 — SETTINGS / ADMIN / DEVELOPER CONTROL SURFACE ### 15. Turn Settings into a premium admin surface The settings page is much better, but still needs to feel first-class. #### Fix * card hierarchy * spacing between cards * internal spacing within cards * heading hierarchy * back header treatment * developer section hierarchy * danger zone treatment * chat/feedback overlap * balance between profile, notifications, developer, and danger sections #### Target Settings should feel calm, premium, and intentional. *** ### 16. Make API Keys / Webhooks feel truly real If self-serve exists, it must feel serious. #### Fix * expose real safe metadata cleanly * explain one-time secret/key visibility clearly * explain revoke/delete behavior clearly * explain current availability constraints truthfully if still limited * ensure cards do not feel empty or placeholder-ish * if needed, improve status/empty states and action controls #### Target A developer should believe FleetOS is a real integration platform. *** ## PART 6 — HOMEPAGE / MARKETING / BRAND EXPRESSION ### 17. Upgrade mobile homepage to premium SaaS quality #### Fix nav/header * improve logo/nav/cta spacing * improve readability of Pricing / Docs / API / Login * ensure mobile menu feels premium * ensure sticky behavior is clean #### Fix hero * tighten headline wrapping * tighten subheadline spacing * improve CTA hierarchy and spacing * refine demo CTA clarity * ensure device mockup feels proportional and premium #### Fix feature sections * improve body-copy readability * reduce long-block fatigue * tighten section spacing and rhythm * ensure chips/segment buttons feel consistent #### Fix footer * improve footer link readability * improve spacing/grouping * improve help/recovery/support readability * ensure developer/docs links are easy to find and tap #### Target Landing page should look like a premium product company, not just a strong prototype. *** ### 18. Tighten marketing copy throughout #### Fix * shorten bloated paragraphs * improve line breaks on mobile * remove awkward copy * keep tone operational, direct, believable * ensure every section answers a clear user question #### Areas to tighten * hero * category/segment section * feature cards * compliance section * integration section * support/help area * footer/support microcopy #### Target Copy should be crisp, credible, and easy to scan on mobile. *** ## PART 7 — DOCS / DEVELOPER DOCS / API CREDIBILITY ### 19. Make docs feel like part of the product #### Fix * mobile readability * section hierarchy * spacing between sections * CTA/button treatment * code block overflow behavior * cross-linking between user docs and API docs #### Target Docs should feel like a polished product surface. *** ### 20. Audit docs truth against implementation #### Verify and fix * user docs vs current UI * developer docs vs actual handlers * settings docs vs actual admin surfaces * API docs vs actual behavior * webhook docs vs actual flow #### Rule No fake maturity. No hidden caveats. *** ### 21. Raise API-doc trust signals #### Fix * expose OpenAPI link/download if possible * explain auth clearly * explain self-serve vs managed behavior clearly * explain webhook behavior clearly * tighten endpoint descriptions * tighten error/retry language * improve environment/version clarity #### Target A real engineer should trust the docs without guessing. *** ## PART 8 — TERMINOLOGY / IA / CONSISTENCY ### 22. Unify terminology across the whole platform Audit and standardize: * work order * request * job * fleet * supplier * client * quote * approval * ready for pickup * in progress / in shop / pending approval / review quote #### Rule Choose canonical user-facing terms and use them consistently in: * dashboard cards * expanded views * settings * homepage * docs * developer docs * API docs #### Target No drift that makes the product feel stitched together. *** ### 23. Standardize information architecture logic #### Audit and fix * top-level nav language * dashboard tabs * settings card order * docs section order * footer groupings * CTA priority ordering #### Target The whole product should feel like it was planned as one system. *** ## PART 9 — ACCESSIBILITY / BEST PRACTICE / ROBUSTNESS ### 24. Accessibility pass #### Fix * text contrast everywhere * tap target sizes * aria labels on floating buttons, close buttons, key actions * focus visibility * keyboard usability where relevant * semantic heading structure on landing/docs pages * placeholder vs entered-text distinction #### Target Practical strong accessibility, not just aesthetics. *** ### 25. Empty / loading / error / success states pass #### Fix * loading states * upload states * empty states * error banners * success overlays * disabled controls * waiting states #### Target Nothing should feel dead, ambiguous, or unfinished during transitions. *** ### 26. Mobile performance + polish pass #### Fix * excessive glows/shadows if they hurt clarity * modal scroll quality * expanded card scroll behavior * safe-area spacing * overlay collisions * FAB overlap behavior * any small jank caused by layout or fixed elements *** ## PART 10 — API / SECURITY / ARCHITECTURE CONSTRAINTS TO PRESERVE ### 27. Keep developer-platform security credible #### Verify and preserve * no sensitive key/secret fields leak to client-readable paths * API key/webhook story remains truthful * developer settings remain secure and clear *** ### 28. Keep shadow layer optional and well-behaved #### Verify and preserve * no fragile hard dependency from core workflow into shadow layer if avoidable * no silent swallow patterns for important failures * instrumentation remains additive *** ### 29. Preserve maintainable architecture while polishing #### Rule Do not hack polish into giant messy components. Refactor cleanly where needed. Keep code maintainable and typed. *** ## PART 11 — SCREENSHOT-SPECIFIC ISSUES THAT MUST BE CLOSED ### Dashboard / cards * make secondary labels brighter and more readable * keep No photos attached readable * make Pending state clearly visible * strengthen Add Part affordance * reduce floating button interference * keep card CTAs clean and intentional ### Add Job modal * improve label contrast * improve placeholder contrast * improve more-options treatment * ensure modal feels premium and not heavy ### Feedback modal * improve label contrast * improve placeholder readability * improve primary/secondary button balance * ensure it matches Add Job modal quality ### Settings * improve developer card depth and hierarchy * improve spacing in notifications and developer sections * prevent chat button overlap with controls ### Homepage / marketing * improve body-copy readability in feature sections * improve footer link readability * improve CTA rhythm and hierarchy * tighten support/help microcopy readability *** ## EXECUTION ORDER ### Phase 1 — Contrast/readability/affordance Fix all low-contrast text, weak control borders, washed-out states, and interaction clarity issues first. ### Phase 2 — Mobile dashboard and FAB polish Fix card readability, schedule block, response block, and floating control interference. ### Phase 3 — Modals and settings polish Upgrade Add Job, feedback modal, settings/admin surfaces. ### Phase 4 — Homepage / marketing polish Upgrade readability, spacing, trust, and premium feel on the landing site. ### Phase 5 — Docs and developer docs polish Ensure docs quality matches product quality and truthfulness. ### Phase 6 — Terminology / consistency / cleanup Do the final sweep across the whole product. ### Phase 7 — Verification Run mobile and desktop checks across: * supplier dashboard * fleet dashboard * add-job flow * settings flow * docs/dev-docs flow * homepage/marketing flow *** ## REQUIRED OUTPUT STYLE WHILE WORKING * Be concrete. * Show exact files changed. * Keep a running checklist. * Make incremental commits. * Call out visual-token changes explicitly. * Call out doc/product mismatches explicitly. * Preserve truthfulness while increasing polish. *** ## FIRST RESPONSE FORMAT Your first response must contain exactly these sections: 1. `Global polish gaps` 2. `Highest-priority UI/UX fixes` 3. `Marketing/docs gaps` 4. `Architecture/API constraints to preserve` 5. `Execution plan` 6. `First files I will change` Then start work. *** ## DEFINITION OF DONE You are done only when FleetOS feels 10/10 in all of these: * supplier dashboard * fleet dashboard * mobile readability * add-job flow * settings/admin flow * homepage/marketing site * docs / developer docs * product trust / terminology / consistency * developer-platform credibility The standard is: premium, coherent, readable, credible, production-minded, and obviously better than “good enough.” --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://t420.gitbook.io/t420/claude-everything-10of10-final.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.