Course arrival actions + fix sweep: contact CTA event, claims/bricks/reading-list fixes

.okf/design/house-visual-spec.md

@@ -23,6 +23,16 @@ generated:
 | Labels | INSIDE shapes (Sweller split-attention rule); never bare diamonds |
 | Dashes | "-" only, including inside artwork |
 
+# Fit text for the fallback font, not Caveat (2026-08-20)
+
+Hand SVGs load via `<img>`, where the Caveat webfont never applies - the
+browser renders the `cursive` fallback (Comic Sans-class), which runs
+~30% WIDER than Caveat. Both retros-post exhibits clipped on first render
+because strings were sized for Caveat metrics. Budget ~0.55em average
+glyph width per character at a given font-size when fitting strings to
+boxes, and render-verify before commit - the mermaid pipeline dodges this
+by embedding the woff2, hand SVGs don't.
+
 # Exemplars
 
 `invoice-loop.svg` (ai-token-bill) and `network-buckets.svg` are the

.okf/log.md

@@ -1810,6 +1810,39 @@ GA4 deliberately not pulled - §5 establishes ~85-90% bot traffic and
    post's SVG for the rest of the session. Sweep artwork text whenever a body
    phrase is banned or changed.
 
+## 2026-08-20 — Aug-20 analytics read: contact CTA instrumented, dead-click calibration, title-pass veto held
+
+1. **`contact_cta_click` GA4 event shipped** (seo-review-2026-08-13 §6 #1, its
+   top open item). Delegated listener in
+   `themes/beaver/layouts/partials/page/analytics.html` inside the GA block —
+   catches every `a[href*="/contact-us"]` site-wide, no per-template wiring.
+   Pending 1-click GA4-admin step (Paul): mark it a key event.
+2. **Clarity "dead clicks" on plain paragraphs are reading behavior, not
+   defects.** `reference/paid-pilot-full/` was the site's #1 dead-click page
+   (17/7d); recordings show clicks on the opening prose paragraph, traffic part
+   internal Clarity-replay, part genuine ChatGPT referrals. Calibration: a
+   dead-click hotspot is only actionable when the clicked element LOOKS
+   interactive. Recorded in the 2605 tracker so nobody "fixes" it later.
+3. **Before any title/meta/CTR work, check seo-review-2026-08-13 §6 first.**
+   Item #5 records title rewrites as a falsified experiment (wave 1 lost
+   impressions). An approved plan step (course SERP CTR pass) was dropped
+   mid-execution on this evidence — premise-audit beat plan-momentum.
+4. Course arrival reality (28d): ~12 Google organic, ~7 ChatGPT/Perplexity,
+   ~4 LinkedIn. AI-assistant channel runs 94% engagement — AEO works; search
+   CTR does not. All 16 LinkedIn drafts already carry full UTM tags.
+
+## 2026-08-20 — Hand-SVG exhibits: the fallback-font width trap; blog visual pass begins
+
+1. **`<img>`-loaded hand SVGs render the cursive FALLBACK, not Caveat** - it
+   runs ~30% wider, so strings fitted to Caveat metrics clip. Rule added to
+   [house-visual-spec](design/house-visual-spec.md): fit for ~0.55em/char and
+   render-verify. Mermaid SVGs are immune (woff2 embedded by bin/render-mermaid).
+2. Wave G blog posts shipped text-only; Paul flagged reader-attention risk.
+   switch-dev-shops got mermaid timeline + decision cards (LR timelines fail
+   at 390px - use TD), retros got two non-mermaid hand exhibits per
+   /impeccable. Course pages: broken Toptal path fixed
+   (toptal.com/developers/cto is canonical), competitor listings (AI People
+   Agency, Seedium) replaced with JetThoughts entries.
 ## 2026-08-20 - CfT 141->152 bump: local dtest re-record on ARM Mac planted false CI drift
 
 The rule already existed in this bundle - test-gates.md has carried "never

content/blog/asked-simple-admin-panel-built-spaceship/index.md

@@ -81,11 +81,3 @@ Third, test the brief before sending it to a human. Paste it into Claude or Chat
 You don't have to switch shops to try any of this - the change is in the next spec you send. If you hand the same team a page with no blank spaces and the spaceship still shows up, that's a different problem, and [there's a separate guide for that conversation](/blog/fire-dev-shop-guide/).
 
 At JetThoughts we've been building Ruby on Rails apps (the web framework we work in) since 2008, and a steady share of that work is taking over projects where the spaceship already landed. If you're staring at one now, we do a free 45-minute code audit: one senior developer reads your codebase - all the code behind your product - and writes you a one-page assessment of what to keep and what to delete. No contract and no follow-up calls after.
-
-## Further reading
-
-- [Mountain Goat Software: user stories](https://www.mountaingoatsoftware.com/agile/user-stories)
-- [Alan Klement: Replacing the user story with the job story](https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27)
-- [Intercom: Designing features using job stories](https://www.intercom.com/blog/using-job-stories-design-features-ui-ux/)
-- [Basecamp: Shape Up](https://basecamp.com/shapeup)
-- [Martin Fowler: Yagni](https://martinfowler.com/bliki/Yagni.html)

content/blog/cheap-developers-expensive-without-cto-review/index.md

@@ -80,8 +80,4 @@ For more on watching a team you can't technically evaluate, see [how to know wha
 
 ## Further reading
 
-- [Google Engineering Practices: How to do a code review](https://google.github.io/eng-practices/review/)
-- [Microsoft Research: Expectations, Outcomes, and Challenges of Modern Code Review](https://www.microsoft.com/en-us/research/publication/expectations-outcomes-and-challenges-of-modern-code-review/)
-- [GitHub Docs: About protected branches and required reviews](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)
 - [SmartBear: State of Code Review](https://smartbear.com/state-of-software-quality/code-review/)
-- [OWASP Top Ten](https://owasp.org/www-project-top-ten/)

content/blog/dev-shop-contract-code-ownership/index.md

@@ -64,7 +64,9 @@ Skip it and you learn the difference at the worst possible moment, usually the w
 
 ## Clause 4: AI-assisted code gets disclosed and warranted
 
-Most agency contracts written before 2023 say nothing about a model writing part of your code, and the copyright rules caught up in 2025. In January of that year the US Copyright Office published Part 2 of its AI report and drew a firm line: material generated by a model without meaningful human authorship is not copyrightable at all, and detailed prompting on its own does not create authorship. [Jones Day's summary](https://www.jonesday.com/en/insights/2025/02/copyrightability-of-ai-outputs-us-copyright-office-analyzes-human-authorship-requirement) is the readable version; the [Copyright Office's own AI page](https://www.copyright.gov/ai/) carries the full reports. Practically, an assignment clause can only transfer rights that exist. If a chunk of your product has no copyright behind it, your competitor can copy that chunk and you have no infringement claim.
+Most agency contracts written before 2023 say nothing about a model writing part of your code, and the copyright rules caught up in 2025. In January of that year the US Copyright Office published Part 2 of its AI report and drew a firm line: material generated by a model without meaningful human authorship is not copyrightable at all, and detailed prompting on its own does not create authorship. [Jones Day's summary](https://www.jonesday.com/en/insights/2025/02/copyrightability-of-ai-outputs-us-copyright-office-analyzes-human-authorship-requirement) is the readable version; the [Copyright Office's own AI page](https://www.copyright.gov/ai/) carries the full reports.
+
+Practically, an assignment clause can only transfer rights that exist. If a chunk of your product has no copyright behind it, your competitor can copy that chunk and you have no infringement claim.
 
 So ask for two things in writing. Disclosure of which AI tools the team uses and how output gets reviewed, and a warranty that generated code and every dependency it pulled in are free of third-party license claims. We wrote up the accountability side of this in [AI code has an owner problem](/blog/ai-code-ownership-accountability/), including what investors have started asking during diligence.
 
@@ -91,11 +93,3 @@ The pre-signature version of this check lives in the [ownership checklist](/cour
 None of this makes the code good; ownership is only what you reach for after something has already gone wrong. You can own every line of a codebase that has no tests and no deploy script, and the paperwork will not shorten the rescue by a day. Clauses cost you something too: a startup lawyer bills real hours to redline an agency MSA properly, a few agencies will walk rather than sign a contributor warranty, and the negotiation adds a week or two before anyone writes code.
 
 So keep the trade narrow. Contract work protects your ability to leave and to sell the company later, and that is all it does. Keeping the code healthy is a separate job that needs [someone reviewing the work every week](/blog/code-quality-evaluation-non-technical-founders/), not a paragraph in an MSA.
-
-## Further reading
-
-- [US Copyright Office, Circular 30: Works Made for Hire](https://www.copyright.gov/circs/circ30.pdf)
-- [17 U.S.C. §101 - definitions, including "work made for hire"](https://www.law.cornell.edu/uscode/text/17/101)
-- [Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989)](https://supreme.justia.com/cases/federal/us/490/730/)
-- [Jones Day: Copyrightability of AI outputs and the human authorship requirement](https://www.jonesday.com/en/insights/2025/02/copyrightability-of-ai-outputs-us-copyright-office-analyzes-human-authorship-requirement)
-- [US Copyright Office: Copyright and Artificial Intelligence](https://www.copyright.gov/ai/)

content/blog/dev-shop-sla-requirements-checklist/index.md

@@ -34,7 +34,9 @@ Keep the five examples handy. You'll want them in the room when the sales lead s
 
 ## Requirement 1: first response in hours, split by severity
 
-The clause you want reads something like: "Severity 1 incidents receive a first response from an engineer within 2 business hours. Severity 2 within 8 business hours. Severity 3 within 2 business days."
+The clause you want reads something like:
+
+> "Severity 1 incidents receive a first response from an engineer within 2 business hours. Severity 2 within 8 business hours. Severity 3 within 2 business days."
 
 A severity level is just a ranking of how bad the problem is: level 1 means the app is down or customers can't pay you, level 2 means a feature is broken but users can work around it, and level 3 covers typos and cosmetic glitches. Atlassian publishes a plain-English [severity scale](https://www.atlassian.com/incident-management/kpis/severity-levels) you can copy into the contract so both sides rank problems the same way.
 
@@ -89,11 +91,3 @@ A resolution clock also creates a new incentive you should watch: a team racing
 If you can't tell whether slow replies are a service problem or a code problem, we do a free 45-minute code audit: one senior developer, your codebase, a written one-page assessment. We've worked in Rails since 2008 and 95% of our clients stay with us - numbers we're comfortable putting in a contract, which is rather the point of this post. [Get the audit](https://jetthoughts.com/contact-us/).
 
 Start with the inbox measurement tonight. It needs no lawyer, and by Friday you'll know which of the five clauses to fight for first.
-
-## Further reading
-
-- [Google SRE Book: Service Level Objectives](https://sre.google/sre-book/service-level-objectives/)
-- [AWS Compute Service Level Agreement](https://aws.amazon.com/compute/sla/)
-- [Atlassian: SLAs - what they are and how to manage them](https://www.atlassian.com/itsm/service-request-management/slas)
-- [Atlassian: Understanding incident severity levels](https://www.atlassian.com/incident-management/kpis/severity-levels)
-- [Stripe's public status page](https://status.stripe.com/)

content/blog/retros-founder-transparency-tool/index.md

@@ -48,36 +48,29 @@ Ask for a one-page summary after each retro. Skip the raw notes, and skip the in
 
 Here is the shape of a useful one:
 
-```text
-Cycle 34 retro summary - 2026-07-24
-
-What went well
-- Payment retry fix shipped Tuesday, no rollbacks.
-- New staging environment cut deploy time from 22 min to 6 min.
-
-What slowed us down
-- Waited 4 days on API credentials from the client side.
-- Two of six days lost to a flaky test suite on the checkout flow.
-
-Changes we're making
-1. Quarantine the flaky checkout tests by Friday (owner: Dana).
-2. One named person on the client side for credential requests (owner: founder).
-
-Carried over from last cycle
-- Flaky checkout tests. Third cycle in a row.
-```
+![The one-page retro summary, annotated: four blocks - what went well, what slowed us down, changes we're making with named owners, and a red-flagged carried-over block - with margin notes saying to read the carried-over block first, that the same item on its third cycle is your loudest warning sign, and that a task on your side means the retro isn't sanitized](retro-summary-annotated.svg)
 
 That last block is the whole reason to ask for the document.
 
 ## The one line that tells you the most
 
-Read the carried-over section before anything else. An action item that appears in three consecutive retros is a team that has diagnosed a problem, agreed on the fix, and cannot get to it. Sometimes that is your fault, because you keep adding scope on top. Sometimes the fix is much harder than they said in the room, which is worth a direct question. And sometimes the team simply lacks the authority to act: if their developers cannot spend two days on the test suite without a change order from their account manager, the same item will surface forever, which tells you the constraint sits in the commercial relationship rather than in engineering. Either way it is a live signal you can act on this week without knowing what a flaky test is.
+Read the carried-over section before anything else. An action item that appears in three consecutive retros is a team that has diagnosed a problem, agreed on the fix, and cannot get to it.
+
+- Sometimes that is your fault, because you keep adding scope on top.
+- Sometimes the fix is much harder than they said in the room, which is worth a direct question.
+- And sometimes the team simply lacks the authority to act: if their developers cannot spend two days on the test suite without a change order from their account manager, the same item will surface forever, which tells you the constraint sits in the commercial relationship rather than in engineering.
+
+Either way it is a live signal you can act on this week without knowing what a flaky test is.
 
 Notice that the sample above puts a task on the founder. A retro that never generates work for your side is a retro that has been sanitized before it reached you, and sanitized retros are the common failure mode rather than missing ones. Stefan Wolpers catalogued [twenty-one retrospective anti-patterns](https://age-of-product.com/sprint-retrospective-anti-patterns/) if you want to see how many ways this meeting can go quietly hollow.
 
 ## How to ask for it without starting a fight
 
-Frame it as a request for a document rather than a change to how they work. Something close to: "Do you run retrospectives at the end of each cycle? If so, could you send me a short written summary after each one - what went well, what slowed you down, what you're changing, and anything carried over? I don't need to attend." That phrasing gives them the format and takes the meeting off your calendar in the same sentence, and any team that already runs retros will say yes in under a minute.
+Frame it as a request for a document rather than a change to how they work. Something close to:
+
+> "Do you run retrospectives at the end of each cycle? If so, could you send me a short written summary after each one - what went well, what slowed you down, what you're changing, and anything carried over? I don't need to attend."
+
+That phrasing gives them the format and takes the meeting off your calendar in the same sentence, and any team that already runs retros will say yes in under a minute.
 
 Watch what comes back. A team that has been running retros produces the first summary within a cycle, sometimes by forwarding one they already wrote. Teams that have not been running them either start, which is a win, or explain that their process is too lightweight for that, which is the answer you were fishing for. Refusal to write anything down at all belongs on the same list as the [other dev shop red flags](/blog/dev-shop-red-flags-checklist/).
 
@@ -87,6 +80,8 @@ A team can write an honest, useful retrospective about a product that still cras
 
 For that you need the other half: a fifteen-minute session where somebody clicks through the actual product in front of you. The [Friday demo rule](/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/) in the course covers the format and the questions to ask during it. Pair the two and you have process health on one page and working software on a screen, which between them close most of the gap that makes founders anxious between invoices.
 
+![Process on one page, product on a screen: a retro card - one page per cycle on how the work went - plus a Friday demo card - fifteen minutes of clicking through the live product - converging on one result: between invoices, nothing left to guess](retro-plus-demo.svg)
+
 The habit is not free. An hour per cycle for the meeting, plus the work the team commits to, comes out of the same budget as features. Our own team runs a written retrospective at the end of every seven-day cycle, described in [async remote XP practices](/blog/async-remote-xp-practices/), and the fixes that come out of it regularly eat a day of the next cycle. It is part of why our client retention runs about 95%, and also why our velocity in any single week looks slower than a shop that skips it.
 
 Both of these are downstream of one habit: [knowing what your team is doing](/blog/how-know-what-your-team-doing-remote-startup/) through written artifacts rather than reassurance on calls.
@@ -96,11 +91,3 @@ Both of these are downstream of one habit: [knowing what your team is doing](/bl
 On your next call, ask when the team last ran a retrospective and what came out of it.
 
 You will get a specific answer with a date and an action item, or you will get a pause while they reach for one. The pause tells you more than the tidy answer would have, and either way you know something this week that you did not know on Monday.
-
-## Further reading
-
-- [The 2020 Scrum Guide](https://scrumguides.org/scrum-guide.html)
-- [Scrum.org: what is a sprint retrospective](https://www.scrum.org/resources/what-is-a-sprint-retrospective)
-- [Tannenbaum & Cerasoli, "Do team and individual debriefs enhance performance? A meta-analysis"](https://pubmed.ncbi.nlm.nih.gov/23516804/)
-- [The same meta-analysis in *Human Factors*](https://journals.sagepub.com/doi/abs/10.1177/0018720812448394)
-- [Stefan Wolpers: 21 sprint retrospective anti-patterns](https://age-of-product.com/sprint-retrospective-anti-patterns/)