/* Review layer — citable section codes for the Dylan / Donnie / Luigi page-by-page review. * * Every reviewable block on the site carries a small yellow tab, "Section BD". The first letter * is the page, the second the block on it, so "Section BD" on their recording resolves without * ambiguity: page B (Home), fourth block. A = elements that repeat on every page (header, * closing band, footer); Z = the utility pages. * * Mode: on by default on the staging site. `?review=off` or the Hide button turns it off for * a clean read; the choice is remembered in localStorage. `?review=on` forces it back on. * * Mike, 17 Sept, final pass: "turn all the sticky notes into yellow ones that don't show any * additional info, we can just leave the section labels for us communicating about them as a * team." Every tab (Tab, IllustrationNote) is now a plain, non-interactive yellow label — no * red/orange states, no click-to-open note, no "Open all notes" toolbar button. The REVIEW and * ILLUSTRATIONS objects below still exist and still drive review.html's own index (so the codes * keep mapping to a page and a plain-English name), but none of their other fields — outstanding, * verified, open, unverified, visual, ask — render anywhere anymore. They're left in place as the * record of what each round of review actually asked and decided, the same way git history is; * add a new code there before using it, but nothing you write in those fields will surface on the * live site. Everything before this pass (the rules about verified/open/unverified copy, v2's red * "outstanding" tabs, the orange illustration asks, the 9 Sept shared-savings proposal) is exactly * that: history, readable in this file's own git blame, not a spec for what renders today. */ const REVIEW_PAGES = { A: { page: 'Every page', href: 'index.html' }, B: { page: 'Home', href: 'index.html' }, D: { page: 'Platform overview', href: 'platform.html' }, E: { page: 'Security & trust', href: 'platform-security.html' }, F: { page: 'Pricing & licensing', href: 'platform-licensing.html' }, G: { page: 'Migration & evaluation', href: 'platform-migration.html' }, /* H (Technical documentation) removed for launch, 17 Sept — Mike, HourPlus call, confirmed against the transcript: "should I just remove this for the launch?" / Dylan: "yeah... potentially for the launch." An SDK/API reference and an architecture white paper come later, once they exist to link to. */ I: { page: 'Industries', href: 'industries.html' }, J: { page: 'Managed service providers', href: 'industries-msp.html' }, K: { page: 'Government: Tactical / DDIL', href: 'industries-government-tactical-ddil.html' }, L: { page: 'Government: Regional', href: 'industries-government-regional.html' }, M: { page: 'Commercial: Regulated industries', href: 'industries-regulated.html' }, N: { page: 'Commercial: Enterprise virtualization', href: 'industries-enterprise-virtualization.html' }, C: { page: 'Commercial: Oil & gas', href: 'industries-oil-gas.html' }, X: { page: 'Commercial: Telecommunications', href: 'industries-telecommunications.html' }, Y: { page: 'Government: Enterprise compute', href: 'industries-government-enterprise.html' }, O: { page: 'Compare', href: 'compare.html' }, P: { page: 'Compare: VMware', href: 'compare-vmware.html' }, R: { page: 'Compare: Nutanix', href: 'compare-nutanix.html' }, S: { page: 'Compare: Red Hat', href: 'compare-red-hat.html' }, U: { page: 'Plan a controlled evaluation', href: 'evaluation.html' }, V: { page: 'Run the numbers', href: 'run-the-numbers.html' }, Z: { page: 'Utility pages', href: 'about-triq.html' }, }; const REVIEW = { /* AA–BG below carry `v2: true` and one field, `outstanding` — what still needs a decision. Empty (or absent) means resolved: the Tab renders as a plain label, not a note. Everything from CA down is unchanged from the review Dylan, Donny and Luigi actually did — Platform, Solutions and Compare still get their own pass. */ AA: { section: 'Header and navigation', v2: true, outstanding: [] }, AB: { section: 'Closing band — Two ways to get started', v2: true, outstanding: [] }, AC: { section: 'Footer', v2: true, outstanding: [] }, BA: { section: 'Hero', v2: true, outstanding: [] }, BB: { section: 'What changed', v2: true, outstanding: [] }, BC: { section: 'What your team gets back', v2: true, outstanding: [] }, BD: { section: 'One control plane built to keep running', v2: true, outstanding: [] }, BE: { section: 'Managed without opening a door', v2: true, outstanding: ['Donny to confirm the exact scope of "no inbound management ports."'] }, BF: { section: 'Migration', v2: true, outstanding: [] }, /* BG ("Go deeper — architecture and security model") removed outright, 17 Sept: Mike — "get rid of that." Its only two links were the technical architecture page (also removed this round) and the security model page, already reachable from the Platform nav. BH ("Trust" — security posture, support, viability, roadmap, certification, evidence, with the measured-boot/key-released illustration) is gone as of the 15 Sept Triq V2 walkthrough. Luigi, on the illustration: "I have no idea what this is about. This whole section, I would honestly trash it." */ DA: { section: 'Platform overview — opening', v2: true, outstanding: [] }, DB: { section: 'Platform overview — blocks', v2: true, outstanding: ['Approve the agent model and "what runs on it" claims (§5.13).'] }, DC: { section: 'Platform overview — table of contents', v2: true, outstanding: [] }, EA: { section: 'Security & trust — opening', v2: true, outstanding: [] }, EB: { section: 'Security & trust — blocks', v2: true, outstanding: ['Confirm the exact count of recorded action types (§5.13 row 13).', 'Confirm the structural-isolation claim.', 'New, 16 Sept, HourPlus call: split into "What makes us special" and "Table stakes" — confirm the NIAP/FIPS 140-3/government-market claims read right.'] }, FA: { section: 'Pricing & licensing — opening', v2: true, outstanding: [] }, FB: { section: 'Pricing & licensing — blocks', v2: true, outstanding: ['Flat pricing vs. Dylan\'s shared-savings model — which one ships?', 'Publish the worked example ($500K cluster \u2192 ~$100K/year) if shared-savings ships instead?'] }, FC: { section: 'Pricing & licensing — live cost box', v2: true, outstanding: ['Same open rate questions as the other cost calculators — see Run the numbers.'] }, GA: { section: 'Migration & evaluation — opening', v2: true, outstanding: [] }, GB: { section: 'Migration & evaluation — blocks', v2: true, outstanding: ['Confirm step timings (weeks 1\u20133, weeks 3\u20138).', 'Does Basalt perform the migration as a paid service?', 'Draft the actual rollback story.'] }, /* Mike, 15 Sept — Triq V2 walkthrough: "Solutions becomes Industries" — Commercial (MSP, oil & gas, telecommunications, regulated industries, enterprise virtualization) and Government (tactical/DDIL, regional, enterprise). Federal/DDIL edge and Remote/resilient edge already had real content, drafted from Dylan's plan and the 9/10 call — they're refiled as Government pages below (K/L keep their own letters) rather than rewritten, since the content itself didn't change, only where it sits in the nav. MSP is new, real content straight from this call (Donnie's multi-tenancy explanation) rather than a placeholder. Mike, 16 Sept, later the same review: "this is terrible work... you're going to have to create the page holder copy for each one of these commercial ones as well as the accompanying illustration" — said of oil & gas, regulated industries, and enterprise virtualization by name, and telecommunications by the same "each one of these commercial ones" scope. All four moved from the generic Placeholder scaffold to real first-draft content and a purpose-built illustration (see C/X/M/N below). Only government enterprise compute (Y) stays a placeholder — Mike asked whether that category was really discussed on the call rather than asking for it to be built; it was (Luigi, [1:34:55]: "the enterprise compute, which is like, you know, true data center, big, lots of racks"), but no brief exists yet beyond that one line. */ IA: { section: 'Industries — opening', v2: true, outstanding: [] }, IB: { section: 'Industries — Government', v2: true, outstanding: [] }, IC: { section: 'Industries — Commercial', v2: true, outstanding: [] }, JA: { section: 'Managed service providers — opening', v2: true, outstanding: [] }, JB: { section: 'Managed service providers — blocks', v2: true, outstanding: ['Confirm MSP framing against Dylan or Luigi\'s own read of the buyer.'] }, KA: { section: 'Government: Tactical / DDIL — opening', v2: true, outstanding: [] }, KB: { section: 'Government: Tactical / DDIL — blocks', v2: true, outstanding: ['Approve "two servers, no outside witness" for public copy.', 'State the real accreditation status (held / in evaluation / not claimed).'] }, LA: { section: 'Government: Regional — opening', v2: true, outstanding: [] }, LB: { section: 'Government: Regional — blocks', v2: true, outstanding: ['Same "two servers, no outside witness" approval needed as Tactical/DDIL.'] }, MA: { section: 'Commercial: Regulated industries — opening', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, MB: { section: 'Commercial: Regulated industries — blocks', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, NA: { section: 'Commercial: Enterprise virtualization — opening', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, NB: { section: 'Commercial: Enterprise virtualization — blocks', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, CA: { section: 'Commercial: Oil & gas — opening', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, CB: { section: 'Commercial: Oil & gas — blocks', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, XA: { section: 'Commercial: Telecommunications — opening', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, XB: { section: 'Commercial: Telecommunications — blocks', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, YA: { section: 'Government: Enterprise compute — opening', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, YB: { section: 'Government: Enterprise compute — blocks', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, OA: { section: 'Compare — opening', v2: true, outstanding: [] }, OB: { section: 'Compare — the list', v2: true, outstanding: [] }, OC: { section: 'Compare — mega comparison table', v2: true, outstanding: [] }, OD: { section: 'Compare — also weighing your options', v2: true, outstanding: ['Mike, 17 Sept, tentative ("I almost feel like..."): confirm this light-mode placement and content works, or whether it wants an actual secondary comparison table instead of the StatRow points reused from each featured page.'] }, PA: { section: 'VMware — opening', v2: true, outstanding: [] }, PB: { section: 'VMware — blocks', v2: true, outstanding: ['Cite the sentiment data (46-to-1 unhappy) by source, or leave unattributed?'] }, PC: { section: 'VMware — cost estimate', v2: true, outstanding: ['Hours-per-platform is still an estimate, not a published benchmark — the wage is a real BLS figure.'] }, PD: { section: 'VMware — feature comparison table', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, PE: { section: 'VMware — management-overhead narrative', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, PF: { section: 'VMware — also considering', v2: true, outstanding: ['New, 17 Sept, HourPlus call, second pass: was three link-out cards, now the management-layer narrative Mike asked to fold in here instead. Not yet reviewed by Dylan, Donnie, or Luigi.'] }, RA: { section: 'Nutanix — opening', v2: true, outstanding: [] }, RC: { section: 'Nutanix — cost estimate', v2: true, outstanding: ['Nutanix\'s $37/core rate is still a derived estimate \u2014 needs a real client number to confirm.'] }, RD: { section: 'Nutanix — feature comparison table', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, RE: { section: 'Nutanix — management-overhead narrative', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, RF: { section: 'Nutanix — also considering', v2: true, outstanding: ['New, 17 Sept, HourPlus call, second pass — same as VMware’s own PF. Not yet reviewed by Dylan, Donnie, or Luigi.'] }, /* SA–SF (Red Hat) replace the old Hyper-V/Azure Local entries as of 15 Sept — Triq V2 walkthrough (see the same-day note above IA and pages.jsx's own note above RedHatHero). Reusing S rather than renumbering everything after it. Q (Proxmox), T (Oracle Linux), and W (HPE Morpheus) are gone as of 17 Sept — those three no longer have their own pages; see build_pages.py's own note and pages.jsx's ALSO_CONSIDERING_POINTS for where their content lives now, on PF/RF/SF instead. */ SA: { section: 'Red Hat — opening', v2: true, outstanding: [] }, SE: { section: 'Red Hat — cost estimate', v2: true, outstanding: ['New, 16 Sept, HourPlus call: Red Hat joins the three featured competitors — same live preset calculator VMware and Nutanix already have.'] }, SB: { section: 'Red Hat — blocks', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi against a real OpenShift Virtualization deployment.'] }, SC: { section: 'Red Hat — management-overhead lead', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, SD: { section: 'Red Hat — feature comparison table', v2: true, outstanding: ['Not yet reviewed by Dylan, Donnie, or Luigi.'] }, SF: { section: 'Red Hat — also considering', v2: true, outstanding: ['New, 17 Sept, HourPlus call, second pass — same as VMware’s own PF. Not yet reviewed by Dylan, Donnie, or Luigi.'] }, /* Real page now (pages.jsx's PlanEvaluation), 17 Sept — Dylan's own first note on the call: "the plan controlled evaluation needs copy — right now it's just a placeholder." The 9/9 shared-savings-pilot question below is still genuinely open, just no longer blocking this page from having real copy in the meantime. */ UA: { section: 'Plan a controlled evaluation — opening', v2: true, outstanding: ['Does this page eventually become the shared-savings pilot (one cluster, Basalt does the work, customer pays on results) instead of a plain evaluation? Still open from the 9 Sept call.'] }, UB: { section: 'Plan a controlled evaluation — the four stages', v2: true, outstanding: [] }, VB: { section: 'Run the numbers — the live calculator', v2: true, outstanding: ['Wire the email gate (Resend or Cloudflare) \u2014 a finishing step.'] }, VC: { section: 'Run the numbers — where the funds can go', v2: true, outstanding: [] }, VD: { section: 'Run the numbers — the gate', verified: 'Name and email in exchange for the working is Mike’s 9/7 spec, with no objection from Dylan — “if they want to see how we got that math.” “We do not make you book a call” follows the §5.6 call-to-action rationale.', unverified: ['“One email, no sequence” — conflicts with the plan’s §6 phase 2, a “Run the numbers” drip campaign', 'Asking for a last name', 'Delivery is not wired — Resend or Cloudflare, Mike, a finishing step'], visual: 'None. Suggest none — a form.' }, ZA: { section: 'About Triq', open: ['Company naming — Dylan 9/7: Basalt will likely get its own LLC (§5.13 row 17)', 'What is said about funding and headcount — public or NDA (§5.13 row 18)'], unverified: ['Everything else on the page'], visual: 'A real photograph of the team, or nothing. No stock.' }, ZB: { section: 'Contact', v2: true, outstanding: ['Confirm who actually answers each @triq.tech contact route.'] }, ZC: { section: 'Documentation login', v2: true, outstanding: ['Connect a real identity provider \u2014 a finishing step.', 'Do documentation logins exist at launch, or link out to triq.tech?'] }, ZD: { section: 'Customer portal', verified: 'basalt.trick.tech is the existing customer portal (§1 of the plan).', unverified: ['Whether it is linked from here at launch'], visual: 'None.' }, ZE: { section: 'Privacy', v2: true, outstanding: ['Needs an actual legal review pass.', 'Name third-party vendors and a retention period once decided.'] }, ZF: { section: 'Accessibility', v2: true, outstanding: ['Needs an actual accessibility audit \u2014 badged as a draft until then.'] }, ZG: { section: 'Legal', v2: true, outstanding: ['Needs an actual legal review pass.', 'Needs the real open-source bill of materials.'] }, }; /* Orange notes — one per new or redrawn illustration, a different ask from the section notes above: not "is this wording right" but "does this drawing say the true thing, and is it clear." The code is the section it lives in plus V (for "visual"), so it stays trivial to say out loud on a call — "Illustration B-A-V" — and a second one in the same section gets a 2. */ const ILLUSTRATIONS = { /* BAV (hero globe) approved 17 Sept, no changes asked for — removed per Mike's own rule: a confirmed illustration with nothing outstanding doesn't keep its note. */ BDV: { label: 'One control plane, built to keep running — regions and tenancy on one diagram, replacing the separate FleetMap', ask: 'The spacing from a region’s own label down to its first tenant, and from each tenant’s label down to its icons, opens up — both used to sit only 8px apart. This section was also split off its own drawing from a shared section with the outbound-only one below (see BEV) — same illustration, its own section now. Please confirm this is right, or tell us specifically what doesn’t make sense.' }, BEV: { label: 'Per-site control planes — one controller per site vs. one shared controller', ask: 'New, 16 Sept, HourPlus call: replaces the old two-box NoInboundPorts drawing entirely, per Donnie’s own on-call rejection of it ("I don’t particularly care for this graphic because it doesn’t truly represent the real problem") and the replacement he sketched live ("an island on the left with a bunch of controllers... on the basalt side, a couple of different regions with hosts going outbound into basalt"). Left: three sites, each with its own controller and its own punched hole in its own firewall segment. Right: one Basalt controller behind one solid, gapless wall, reached by three outbound-initiated lines from each site’s own hypervisor (arrows originate at the host, not the controller, per Donnie’s correction), each labeled by tenant.\n\n17 Sept, third pass: "you didn’t label the firewall... that’s not centered on the text, it still seems to be left-justified." Both fixed — the left group’s caption now sits over its own actual center, the left group itself no longer hugs the canvas edge tighter than the right one does, and both firewalls (the per-site boundary on the left, the solid wall on the right) now carry their own "Firewall" label instead of relying only on the caption below.\n\n17 Sept, fourth pass, checked directly against the actual reference sketch: "they are supposed to converge in the middle of the firewall... look like there are 3 separate holes" — fixed by having all three tenant lines meet at one exact point on the shared wall’s own center before continuing as a single line into the controller. Then, same reference: "there’s a firewall around all the incumbent’s hypervisor stacks too" — the left side’s firewall was a small token floating between the controller and the site, not a boundary around the site itself. Rebuilt as a full perimeter wrapping each Site block, with the controller’s own connection as the one gap in it. Please confirm this is right, or tell us specifically what doesn’t make sense.' }, BFV: { label: 'Migration — stand up alongside, validate, migrate in stages', ask: 'Mike, 15 Sept: the validation checkmark is now a solid badge stamped on the corner of the purple (accent) blocks it’s actually validating, instead of a small mark floating above-right of the panel. Luigi: "I look at this picture for a second, I lost the check mark there... that’s why you looked at it for a few seconds." Please confirm this reads clearly now, or tell us specifically what doesn’t make sense.' }, PFV: { label: 'VMware — Proxmox/Morpheus/OLVM on one side of a wall, Basalt alone on the other', ask: 'New, 17 Sept: "put them on one side of a firewall... and Basalt on the other side, and make it stand out that it’s in a class of its own. This is not the same approach as the other ones, even though they’re as inexpensive." Left: Proxmox, Morpheus, OLVM, and "a dozen others," each still marked with its own per-cluster control plane. Right, past the wall: Basalt alone. Both captions say the same low price applies to both sides — architecture is the only thing that differs. Please confirm this reads clearly, or tell us specifically what doesn’t make sense.' }, JBV: { label: 'Commercial: MSP — multi-tenancy illustration', ask: 'New, 16 Sept, per Mike: "you must create an illustration for multi-tenancy for managed service providers." Draws Donnie’s own description: one super-admin controller reaching every customer’s own cluster, and no line at all between customers — not a dashed or blocked one, an absent one, since the claim is that a tenant cannot see another tenant’s environment at all. Please confirm this is right, or tell us specifically what doesn’t make sense.' }, CBV: { label: 'Commercial: Oil & gas — distributed site reach illustration', ask: 'New, 16 Sept, per Mike’s instruction to pair real placeholder copy with "an accompanying illustration." One control plane at the top, reaching down to four remote sites (platform, pipeline station, refinery, terminal) spread along a baseline standing in for distance — deliberately not MSPTenancy’s shape reused verbatim, since this is reach across distance, not tenant isolation. Please confirm this is right, or tell us specifically what doesn’t make sense.' }, XBV: { label: 'Commercial: Telecommunications — distributed site reach illustration', ask: 'Same DistributedSiteReach component as Oil & gas’s own CBV, above, relabeled for telecom sites (cell site, point of presence, substation) rather than redrawn — Luigi gave both industries the same underlying shape on the call. Please confirm reusing one illustration across both pages is right, or tell us if telecommunications needs its own distinct drawing.' }, MBV: { label: 'Commercial: Regulated industries — data custody illustration', ask: 'New, 16 Sept, same pass as CBV/XBV above, but a custody claim rather than a distance one, so it’s a new drawing (DataCustody) rather than DistributedSiteReach reused a third time: your data and Basalt both stay inside your own infrastructure boundary, one outbound-only management line leaves, and a crossed-out arrow marks the access — someone else’s data center — that stays refused. Please confirm this is right, or tell us specifically what doesn’t make sense.' }, NBV: { label: 'Commercial: Enterprise virtualization — reuses the VMware page’s control-plane illustration', ask: 'Deliberately not a new drawing: Luigi’s own description of this page was "the generalized" catch-all commercial case, so it reuses ControlPlaneComparison (built for compare-vmware.html) with a generalized caption instead of a VMware-specific one. Please confirm reusing that illustration here is right, or tell us if this page needs its own.' }, EBV: { label: 'Security & trust — reuses the home page’s per-site control-planes illustration', ask: 'Same new drawing as the home page’s own BEV (see that note for what changed and why), capped at 380px on this page after three earlier passes on its old predecessor (uncapped → 300px → 380px) found that width the right middle ground for this column. Please confirm this is right, or tell us specifically what doesn’t make sense.' }, YBV: { label: 'Government: Enterprise compute — data center scale illustration', ask: 'New, 16 Sept, second pass, per Mike’s instruction to match Tactical/DDIL and Regional’s own structure, which both pair their claim with a purpose-built illustration. One control plane above a tightly-grouped row of racks under one roofline — the opposite composition from DistributedSiteReach’s spread-across-distance shape, since this page is about one facility at scale, not many remote sites. Please confirm this is right, or tell us specifically what doesn’t make sense.' }, /* New, wide-monitor review pass: one illustration per Compare page (Mike: "it needs to basically show that basalt does the exact same thing, it's a virtualization commodity, and it does it the same way if it's a KVM... and if it's the other one, you can show how it does it differently, but it accomplishes the same goal") plus the two Solutions edge pages that KB/LB already said were waiting on a real drawing before going dark. These five use site/diagrams-v2.jsx's own VirtualizationParity / DdilResilience / RestartClassHA — Proxmox, Oracle Linux, and HPE Morpheus had the same treatment (QBV/TBV/WBV) until their own pages were removed, 17 Sept (see the note above SA). */ PBV: { label: 'VMware — control-plane comparison illustration', ask: 'Mike, 15 Sept — replaces the old same-core/different-core parity drawing on this one page. Donnie/Luigi were specific that VMware’s real gap isn’t the kernel: "the big practical difference is the fact that they have a control plane right next to every cluster, and they have to — they don’t have an option." New drawing: three clusters, each with its own vCenter stacked on top of it, beside one basalt control plane reaching three clusters at once. The other five Compare pages keep the same-core/different-core comparison, which is still the right question for those. Please confirm this is right, or tell us specifically what doesn’t make sense.' }, SBV: { label: 'Red Hat OpenShift — parity illustration', ask: 'New, 15 Sept, replacing the Hyper-V / Azure Local page this letter used to hold. Red Hat documents KubeVirt itself as built on KVM, same as Basalt — drawn as a shared core rather than two different paths, same treatment as Proxmox and Nutanix. Please confirm this is right, or tell us specifically what doesn’t make sense.' }, KBV: { label: 'Federal / DDIL — resilience illustration', ask: 'Draws only what KA/KB’s own copy already states publicly — link denied, workloads keep running, delta resync on return — not the "two servers, no witness" phrasing KB’s own note says hasn’t cleared for public copy yet. Section also goes dark/inverse now that there’s a real drawing to pair with it, per KB’s own note. Please confirm this is right, or tell us specifically what doesn’t make sense.' }, LBV: { label: 'Remote edge — resilience illustration', ask: 'Same guardrail as KBV: draws restart-class HA and synchronous replication, exactly as LB’s own copy states, without the still-open witness/server-count claim. Section also goes dark/inverse now that there’s a real drawing, per LB’s own note. Please confirm this is right, or tell us specifically what doesn’t make sense.' }, FBV: { label: 'Pricing & licensing — flat-vs-metered illustration', ask: 'New, 14 Sept, per Mike: this section had no illustration at all. A line chart, not a hardware scene — the one claim it draws is that per-core pricing climbs as the estate grows while Basalt’s flat rate doesn’t. The staircase’s own step count is illustrative of the SHAPE of metered pricing, not plotted from any one vendor’s actual published curve — please confirm that reads as intended rather than as a specific competitor’s real numbers.' }, }; /* ------------------------------------------------------------- components */ /* Mike, 17 Sept: "turn all the sticky notes into yellow ones that don't show any additional info, we can just leave the section labels for us communicating about them as a team." Every open question this whole layer used to carry — red "N to decide" tabs, orange illustration asks, the four-column Detail note, "Open all notes" — is gone. What's left is exactly what that sentence describes: a plain yellow, non-interactive label per block, still citable on a call ("Section BD," "Illustration BEV") but with nothing to open, because there's nothing left to decide. The underlying REVIEW/ILLUSTRATIONS data above still exists and still names each section in review.html's own index — the history just isn't rendered as a note anymore. */ function Tab({ id, top, side, inline, onMouseEnter }) { const style = inline ? undefined : { top, [side]: 'var(--gutter)' }; return ( Section {id} ); } /* Mike, 24 Sept: "get rid of all the little sticky notes, we are finally at the home stretch!" The illustration review is done, so the one sticky note that was still deliberately left on (per the 21 Sept note below) is retired too. Kept as a no-op rather than deleted outright so the many existing call sites across pages.jsx/home.jsx don't need touching. */ function IllustrationNote({ id }) { return null; } /* Mike, 21 Sept: "remove the yellow sticky notes that identify the sections. The only sticky notes I want you to leave are the illustration sticky notes... I am really confident that our sections are good to go." Reviewed wrapped every content block in a "Section XY" tab (via Tab, above) for exactly this kind of tracking during the review passes; that job's done, so it's now a pure pass-through. IllustrationNote (below) is untouched — the illustrations are the thing still being iterated on, per this same instruction. The `#root section` selector in site.css's 1552px+ rule already matches at any depth (its own comment explains why, from when .rv-wrap used to sit between root and section), so dropping that wrapper div here doesn't need a matching CSS change. */ function Reviewed({ id, top = 24, side = 'left', children }) { return {children}; } /* Mike, 24 Sept: "get rid of all the little sticky notes, we are finally at the home stretch!" The fixed bottom-left toolbar (and its own "Show review notes" off-switch button) goes the same way as IllustrationNote above — a no-op, so the existing call sites don't need touching. review.html (the section index it used to link to) and build_page_index.py's own review-code tracking are untouched; both read REVIEW/REVIEW_PAGES/ ILLUSTRATIONS and the tags directly, not through this component. */ function ReviewBar({ page }) { return null; }