> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/public-website/docs/second-pass-failure-accounting-2026-07-05.md). # FactionOS Public Website Second-Pass Failure Accounting Date: 2026-07-05 Scope: accounting of failures, misses, issues, and process problems in the delivered `sites/factionos-public-website/` pass against: * `docs/astro/sites/factionos-public-website/implementation-plan-2026-07-05.md` * `docs/astro/sites/factionos-public-website/design/design-intelligence-2026-07-05.md` * The current homepage implementation under `sites/factionos-public-website/src/pages/index.astro` * The current hero implementation under `sites/factionos-public-website/src/components/home/CommandHero.astro` * Baseline visual inspection performed locally before the requested pause This file is documentation only. It does not change the site implementation. ## Executive Accounting The delivered pass failed the actual goal. It satisfied many technical checklist items, but it did not deliver the promised "dynamic awesome, animation, motion, unique website" from the plan. The output reads like a cautious dark developer-marketing site with a cinematic background and HUD-styled cards, not a premium strategy-game command center for AI-agent work. The core failure was treating route parity, static privacy posture, typecheck/build success, and basic motion hooks as sufficient proof of completion. The project brief explicitly said speed is a performance budget, not a stylistic ceiling. The delivered work inverted that standard: it preserved static safety and checker compliance, but did not push the visual, motion, interaction, and product-proof quality to the stated bar. The implementation also over-exposed internal posture language to visitors. Phrases about synthetic data, static samples, no telemetry, same-data-source accessibility, and no claims became prominent front-facing copy. Those details are important, but the design plan called for them as compact trust labels and boundary proof after product clarity, not as the dominant page voice. ## Top-Level Failure Pattern The pass optimized for "technically green" rather than "visually and experientially correct." That created these systemic problems: * The first viewport is still a headline overlay plus a small status card, not an immersive command-table product surface. * Motion exists, but it is not strong enough to make agent state feel alive. * The page repeats generic cards and section headers instead of building one ownable FactionOS cockpit language. * Privacy and implementation details are too visible too early. * The progress log declared phases complete before the subjective design bar was actually met. * Browser screenshots should have been used as a hard design gate before calling the implementation done. ## Critical Failures ### 1. The Hero Does Not Deliver The Strategy-Game Command Table Thesis Required by the design intelligence: * "Strategy-game command table as the hero, not a split text/card SaaS hero." * "Product UI must be first-viewport signal." * "Desktop: cinematic map surface spans 60-70% of viewport width, copy integrated as command briefing overlay, not in a floating marketing card." * "The site should open on an epic, product-like command table: agent lanes, mission objectives, replay rails, threat markers, approval gates, and local-first boundary signals." Delivered: * A large H1 and body copy dominate the left side. * A single small mission status card sits to the right. * The cinematic poster/video is mostly treated as a background plate. * There is no first-viewport lane roster, event rail, replay rail, approval gate, or inspectable product state as the dominant experience. Why this fails: The first viewport still behaves like a conventional SaaS hero. It borrows a HUD aesthetic, but it does not make the product surface the thesis. The user should immediately feel like they are looking at a command system. Instead, they see a headline and a decorative command-room background. ### 2. The Boot Animation Violates "Copy Readable Immediately" Required by the implementation plan: * "No important text waits for animation." * "Copy and CTAs should be readable immediately." * "Mission Boot Sequence ... CTAs readable immediately." Observed locally: * The initial desktop and mobile baseline screenshots captured the H1, body, and CTAs blurred during the boot sequence. * The CSS applies `filter: blur(3px)` and opacity changes to `[data-boot-item]`, which includes the H1, body, badges, CTAs, and boundary text. Why this fails: The boot sequence made essential content temporarily unreadable. That is the opposite of the stated rule. The boot effect should resolve HUD lines, route traces, state nodes, event rails, and command-core elements while keeping copy readable. ### 3. The Hero Uses A Tiny Status Card Instead Of Product Proof Required: * Agent lanes should move across a tactical grid. * The hero should show objective panel, event rail, map center, and status badges. * Product-like UI must be a first-viewport signal. Delivered: * The hero has one `hero__core-panel` with mission ID, title, a 68% status ring, objective copy, and synthetic label. * The actual lane roster and event timeline are deferred to Section 3. Why this fails: The hero's only foreground product element is too small and too generic to prove the product. It reads as a decorative KPI card. The design called for a tactical board as the first screen, not a small confirmation widget. ### 4. The Page Is Too Text-Heavy And Defensive Required: * Short declarative headlines. * Product proof before privacy detail. * Boundary is visible early but should not bury the product promise. * Avoid letting docs language replace product clarity. Delivered examples: * Hero boundary copy: "Homepage readouts are synthetic static samples only: no analytics, no visitor tracking, no hosted runtime calls." * Mission board lede: "Roster, objective, status, events, and boundaries from one synthetic dataset - the same source drives the visual board and the accessible list below." * Field notes lede: "Product thinking, bounded updates, and roadmap direction - no traction claims." * Multiple sections foreground disclaimers or implementation posture. Why this fails: The visitor is being shown internal launch-safety language. "Same source drives the visual board and accessible list below" is implementation rationale, not product copy. "No traction claims" is a drafting note made visible as marketing copy. These details should be compact trust labels or legal/security proof, not section-level framing. ### 5. The "Development Stuff Front-Facing" Problem Is Real The implementation leaks internal concerns into the public experience: * "static samples" * "same source drives the visual board and accessible list" * "no traction claims" * "no hosted runtime calls" * repeated "synthetic demo data" phrasing * implementation-like boundary explanations in areas that should sell product value Why this fails: The plan required technical precision, not internal process narration. Public copy should help the visitor understand what they control: agents, missions, lanes, hooks, approvals, replay, adapters, and local boundaries. It should not explain how the page was built or overcorrect for claims risk in every section. ### 6. Motion Exists But Does Not Feel Like A Living Agent System Required: * Mission Boot Sequence. * Agent deployment. * Event ingestion. * Review checkpoint. * Command ready. * Tactical scan. * Route trace. * State pulse. * Parallax command layers. * Replay scrub. * Holographic edge. * Section entrances should feel like loading a command deck. Delivered: * Basic CSS boot reveal. * Video play/pause. * Section reveal. * Doctrine glyph reveal. * Route trace in the mission map. * Lane hover/focus opacity highlights. * A small dynamic `motion` import for mission board highlighting. Why this fails: These are technically motion features, but they do not compose into the promised cinematic system. The page does not show a hook event arriving, a lane advancing, a review gate opening, or a risk marker warning in a way that feels central to the product. It mostly reveals static panels. ### 7. The Missing Signal Relay Weakens The Page Rhythm The design intelligence recommended a product-specific counter-panning signal rail between hero and product proof or inside the mission board if it helped continuity. Delivered: * No signal relay was added. * The implementation log says it was "optional" and "not needed." Why this fails: Given the delivered hero was not strong enough as product proof, the signal relay became more important, not less. A kinetic rail of hook events, adapters, statuses, and snapshots would have helped carry the command-system feeling into the rest of the page. ### 8. The Mission Board Is Not Immersive Enough Required: * "Wide unframed command surface." * "Avoid putting cards inside cards." * Agent roster, mission objective, status rings, trace rail, event stream, approval checkpoint, replay marker. * "Developer-tool winners convert with visible product proof before long feature copy." Delivered: * A map panel on the left. * A separate objective panel below it. * A roster and event timeline on the right. * Mostly static layout and simple hover/focus highlights. Why this fails: The board is assembled from conventional panels. It does not feel like one inspectable command surface. It is closer to a dashboard section than a premium cockpit. It needs a more integrated layout: map, lanes, events, replay, and checkpoint state should feel like parts of one tactical instrument. ### 9. The Replay Scrub Is Not Really A Replay Scrub Required: * "Replay scrub, timeline hover/focus highlights the related mission node and route." Delivered: * Lane buttons can highlight related events and nodes. * There is no actual scrub rail or event-by-event replay affordance. Why this fails: The planned interaction was not implemented in substance. Highlighting is not the same as replay. A second pass needs an explicit replay rail with events as selectable ticks, current checkpoint state, and linked map/lane updates. ### 10. The Gaming Feel Is Underbuilt Required: * AAA strategy-game command center meets serious local-first developer infrastructure. * Agent lanes as squads. * Mission objectives, replay rails, threat markers, approval gates, minimap/status rings. * Gaming feel through interface language and cinematic motion, not generic sci-fi decoration. Delivered: * Dark panels. * HUD icons. * Status rings. * Cyber command-room background. * Cards and badges. Why this fails: The pass uses visual vocabulary associated with HUDs, but it does not build the interaction model of a strategy command surface. The "game" feeling is mostly skin-deep. It needs stronger command mechanics: lane deployment, objective tracking, queued review gates, event pings, replay ticks, active routes, locked optional exits, and state changes that animate with purpose. ### 11. The Design Falls Back Into Generic Dark SaaS Dashboard Patterns Required: * Distinctive, ownable command-HUD visual system. * Avoid generic cyberpunk SaaS. * No generic dashboard with logo strips, traces, and vague visibility copy. Delivered: * Many repeated cards with borders, icons, labels, and body copy. * Repeated section header + lede + card grid pattern. * Standard hover border-color and translateY interactions. Why this fails: The page is branded and competent, but not sufficiently unique. The repeated card grammar makes the site feel like a styled component library rather than a bespoke product world. It needs fewer generic cards and more custom surfaces. ### 12. Section Headers And Ledes Are Too Generic Examples: * "More agents can mean less control." * "A command surface for parallel agent work." * "Five tactical loadouts." * "The mission contract, stated plainly." * "Choose your operator path." * "Sources in, local core, optional exits." * "Latest from the mission log." Why this fails: Some of these are acceptable as raw ideas, but the delivery does not sustain a premium command voice. The ledes often explain the design or privacy posture instead of pushing product clarity. The copy needs sharper operator language and less documentation-like caution. ### 13. The Operator Problem Section Does Not Transform Enough Required: * Three before strips: terminal scrollback, session drift, hidden risk. * Each resolves into a FactionOS state label on hover/focus. Delivered: * The before and after states are both visible statically. * Hover/focus does not meaningfully transform raw log fragments into structured state. Why this fails: The section explains the idea, but it does not demonstrate the transformation. A second pass should make each strip feel like a live parsing action: raw terminal lines collapse into mission state, lane assignment, checkpoint, or risk marker. ### 14. The Capability Deck Is A Standard Feature Card Grid Required: * Five tactical loadout tiles. * Tile hover shifts a map overlay behind the deck. * Each tile should feel like equipment/loadout, not generic feature cards. Delivered: * Five cards with icon, label, title, job, boundary chip. * No meaningful map overlay shift behind the deck. * Standard card presentation. Why this fails: The content exists, but the visual and interaction treatment does not meet the "tactical loadout" idea. The deck needs an underlying tactical map or equipment bay that reacts to tile focus. ### 15. Rules Of Engagement Is Still A Disclosure Wall Required: * Mission-contract RulePanel. * Default / Optional / Blocked / No-claim columns. * Expandable sensitive data classes. * Color chips paired with labels. Delivered: * Boundaries and sensitive data classes are present. * The layout is still card/list heavy. * It reads like policy explanation, not a memorable rules-of-engagement command contract. Why this fails: The section is accurate but not designed enough. It should feel like a command contract with locked/default/optional/no-claim states, not a static compliance explainer. ### 16. Provider And Adapter Surface Is Too Static Required: * Equipment bay: sources left, local core center, optional exits right. * Source toggle reveals event-type examples. * Contract language without universal-provider overclaim. Delivered: * Sources, local core, and exits are shown. * No source toggle or meaningful interaction. * The bay is a simple three-column diagram. Why this fails: The section does not feel like equipment selection or adapter routing. It needs a more tactile equipment-bay treatment with route lines, event type examples, and optional exits visually gated. ### 17. Role Routes Are Generic Cards Required: * Squad-selection cards. * Keyboard-accessible cards/segmented control. Delivered: * Four route cards with icon/title/summary/link. * No squad-selection feeling beyond labels. Why this fails: This is another standard card grid. It should look like choosing an operator class/path, with stronger state, selection, and visual identity. ### 18. Final CTA Is Not A Command Console Required: * Command console with Open Demo and Read Docs as large actions. * Destination/posture labels. * Contact tertiary. Delivered: * Uses shared `CalloutCta`. Why this fails: The final section likely inherits a generic CTA component. The plan required a command-console ending. A second pass should replace generic CTA presentation with a purpose-built console surface. ### 19. Mobile Hero Is Not Strong Enough Observed locally: * The initial mobile screenshot showed the H1 and CTA area blurred during boot. * The hero stacks into copy and a core panel rather than a simplified mission board. * The map center and headline compete visually. Required: * "Mobile: compact briefing first, then a simplified vertical mission board with three lane cards." Why this fails: The mobile hero does not become an intentional mobile command briefing. It is the desktop idea compressed. It needs a mobile-specific composition with readable headline, immediate CTAs, and an inspectable simplified lane stack. ### 20. The Visual QA Gate Was Too Weak Required: * Browser QA. * Screenshots. * Core Web Vitals. * Brand fit. * "Any rendering, whitespace, layout, visual, animation, or interaction issue is a launch-blocking bug until fixed." Delivered process: * Technical checks and e2e tests were emphasized. * Screenshots were captured and referenced, but the design quality was still accepted as complete. * A homepage Lighthouse lab LCP note was recorded as 57ms over target but completion still read as done. Why this fails: The QA process let a visually underwhelming pass through because it was technically functioning. The subjective design mandate should have been a blocking gate equal to typecheck/build. ### 21. The Progress Log Overstated Completion The implementation plan progress log marks: * Phase 3 homepage assembly done. * Phase 4 motion pass done. * Phase 5 interior polish and social done. * Phase 6 local/preview done. Why this fails: Those statuses imply the site met the implementation plan. It did not meet the creative and experiential requirements. The progress log should have separated "technical route/checker completion" from "approved visual/motion quality." Marking the work done was misleading. ### 22. Privacy And Static-Site Constraints Were Treated Like The Main Product Required: * Privacy posture preserved. * No runtime fetch, forms, trackers, storage writes, etc. * But also: "Never trade away the spectacle to avoid them." Delivered: * The site strongly preserves privacy posture. * The copy and design repeatedly foreground static/privacy constraints. * The spectacle was not pushed hard enough within the allowed static/CSS/video/vanilla Motion budget. Why this fails: The correct balance was fast, static-safe, and visually exceptional. The delivered balance is static-safe and cautious, with not enough spectacle. ### 23. The Approved Hero Asset Was Underused Required: * Use the Veo command-room plate as the production hero media. * Preserve the dark copy-safe zone. * Add semantic copy and CTAs over the plate. * Make product UI and command board the first-viewport signal. Delivered: * The asset is present. * It is mostly a background visual behind the H1. * Foreground product UI is minimal. Why this fails: The asset should have been part of a composed command interface. The implementation did not add enough foreground HUD structure to make the video/poster feel like an active product surface. ### 24. The Page Does Not Have A Single Memorable Signature Element Required: * Signature effect: Mission Boot Sequence. * Signature image/motion: full-width strategy-game command table. * The site should be remembered for an ownable command-HUD system. Delivered: * The memorable element is mostly the background poster/video. * Foreground UI components are not unique enough. Why this fails: The page needs one unmistakable FactionOS moment. The current pass has pieces, but no signature interaction or composition that makes the brand stick. ## Process Failures ### A. I Let Checklist Completion Replace Design Judgment The work should not have been called done because `pnpm quality`, e2e, link checks, privacy scans, and route parity passed. Those are minimum gates. They do not prove the site meets the visual mandate. ### B. I Did Not Treat The User's Design Direction As The Top Priority The user direction was explicit: * epic gaming feel * animation * motion * unique effects * unique fonts * dynamic awesome website The pass delivered a technically correct foundation with some motion, not a sufficiently epic experience. ### C. I Accepted "Optional" Too Easily The signal relay and deeper kinetic patterns were treated as optional. Given the hero and board were underpowered, those optional elements should have been used to reach the required bar. ### D. I Over-Indexed On Boundary Copy The privacy posture is required, but I let it dominate public language. That made the site feel like it was defending itself instead of selling an operator experience. ### E. I Did Not Stop And Reassess After Seeing The First Screenshots The visual screenshots should have triggered a redesign before any completion claim. The first-viewport composition did not match the plan strongly enough. ### F. I Failed To Separate "Static-First" From "Static-Looking" The site can remain static-output and privacy-safe while still feeling cinematic and dynamic. The delivered pass looks too static and too card-based. ### G. I Did Not Build A Strong Enough Homepage-Specific Component System Reusable components helped ship pages, but they also flattened the homepage into generic cards and panels. The homepage needed more bespoke, section-specific surfaces. ### H. I Did Not Protect The "No Important Text Waits For Animation" Requirement The boot blur on H1/CTA text was a direct miss. That should never have shipped even locally. ## Requirements That Were Met But Not Enough These should not be ignored, but they do not excuse the design failure: * Astro static site exists. * Route parity appears to be implemented. * Self-hosted fonts exist. * The approved hero media is promoted and referenced. * Privacy posture is strongly guarded. * No React/GSAP/Lenis/client router was added. * Basic motion scripts exist. * Reduced-motion handling exists. * Content collections and static endpoints appear to exist. * OG/PWA/LLM endpoints appear to have been added. The problem is not that nothing was built. The problem is that the built work did not meet the promised quality bar. ## Second-Pass Requirements Implied By This Accounting The next pass should not be a light copy edit. It needs a composition and motion redesign while preserving the technical foundation. Priority requirements: 1. Rebuild the hero as an actual command-table surface. 2. Keep H1, CTAs, and essential copy readable from first paint. 3. Move boundary/privacy language into compact trust chips and specific proof moments. 4. Put lane roster, event rail, active route trace, review gate, and replay affordance in the first viewport. 5. Add a kinetic signal relay or equivalent state-transition surface between hero and product proof. 6. Redesign the mission board as one integrated cockpit, not map plus separate cards. 7. Implement a real replay rail interaction, not only lane opacity highlighting. 8. Replace generic card grids with custom tactical surfaces where the plan calls for loadouts, rules, squad routes, adapter bay, and command console. 9. Make mobile a designed command briefing with lane state, not a compressed desktop stack. 10. Re-run visual QA as a blocking gate before marking any phase done. ## Minimum Acceptance Bar For The Second Pass The second pass should not be considered complete until screenshots prove: * The first viewport immediately reads as FactionOS, not generic dark SaaS. * The hero product surface is dominant and inspectable. * The motion system shows agent state changing, not just panels fading in. * Copy is concise and product-facing. * Boundary labels are visible but not overwhelming. * Mobile has its own polished command briefing composition. * Reduced motion still looks intentionally designed. * No essential text is blurred, hidden, or delayed. * The page has at least one memorable signature interaction or composition beyond the hero background asset. ## Bottom Line The delivered pass is a technically organized Astro implementation with a HUD skin. It is not yet the dynamic, animated, motion-forward, unique FactionOS public website described in the plan. The failure is not a missing dependency or a failed build. The failure is a mismatch between the stated creative bar and the delivered experience. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://faction-os.gitbook.io/faction-os-docs/public-website/docs/second-pass-failure-accounting-2026-07-05.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.