The Debrief Desk Corpus

1. Check before you build. Almost every expensive mistake here was a build that a four-minute check would have prevented.

What not to do: Don't build first and check later. We built nine marketplace listings, three books and a long workbook interior before ever asking a marketplace how many people search for the thing.

2. Verify the instrument, then verify the claim. Four separate tools lied to us in two days, all silently.

What not to do: Don't trust a tool because it answered. We took "Subscribed", "Published", "#3", and a cached page at face value. All four were false.

3. A flattering result deserves more scrutiny than a damning one. Nobody investigates good news. That's how we believed we had a #3 placement when we actually had #64.

What not to do: Don't skip verifying good news. We spent zero seconds questioning a #3 placement and an hour questioning a #64 placement. The #3 was the lie.

4. The building was always the cheap part. Knowing what's true was expensive.

What not to do: Don't mistake output for progress. We produced 44 posts, 11 listings, 3 books and a website before producing a single verified fact about demand.

5. A thing that fails silently is worse than a thing that fails loudly. Our test suite refuses to pass an unspecified pattern; every platform tool we touched returned a plausible answer instead of an error.

What not to do: Don't accept a tool that can't fail. We used platform UIs as measurement instruments for two weeks without asking what a failure would look like.

6. Write the prediction down before the data arrives, or any outcome becomes explainable afterwards and nothing is learned.

What not to do: Don't explain a result after seeing it. We nearly read the three books' performance however the day's mood suggested — until we wrote predictions down.

7. Record decisions once, on paper. Two files that disagree are worse than either one alone.

What not to do: Don't leave a contradiction in two files. The feed was "folded to free" in one document and "$19, live" in another, on the same page, for hours.

8. The team's criticism of us was worth more than its ideas.

What not to do: Don't ask a panel what it thinks of your idea and then ignore what it says about your judgement. Their criticism of us was the useful half.

9. A lessons file only compounds if it's alive. (2026-08-19)

What not to do: treat a retrospective as a one-time deliverable — written once at the CEO's request, then left to rot while new mistakes pile up unrecorded, until someone repeats entry #84 verbatim (an agent did, six hours after it was written, because nothing made it read it).

How to do it right: standing order — every session appends its lessons the same day in the three-part format; the daily pipeline checks the day's work for uncaptured lessons; new agent briefs cite the entries relevant to their task. A document that grows daily is an operating manual AND a bottomless content inventory. One that doesn't is a eulogy.

10. Ask the platform what it knows before building for it. Etsy publishes marketplace search volume free. We ran a full set of listings for five days to learn what one query answered in a minute: ~25 searches/month.

What not to do: Don't infer demand from proxies when the platform publishes the real number. We used Google Trends shapes for a week; Etsy had the actual figure behind a free menu item.

11. A keyword is not a product. "Emergency binder" was our best term by volume, ratio and conversion — and on Amazon those words describe a physical binder with pockets we cannot manufacture.

What not to do: Don't build for a keyword without looking at what it returns. We picked "emergency binder" on volume alone. The results are physical binders.

12. Term volume tells you what people TYPE, never what they expect to RECEIVE.

What not to do: Don't assume the searcher wants your format.

13. Look at what the top results actually ARE — format, object, price band — not just the volume behind the words.

What not to do: Don't stop at the volume column. The format of the top results is the more important data.

14. Volume is a ceiling, not a forecast. 2,700 available searches produced one view. Available volume is not traffic.

What not to do: Don't treat available searches as expected traffic. 2,700 available produced one view and we called it a demand finding.

15. A BSR number is not a volume. It proves a category sells; it says nothing about whether you can reach those buyers.

What not to do: Don't quote a BSR number as if it were a volume. BSR #2,961 proves sales exist; it doesn't size them.

16. "The market exists" and "we can reach it" are different questions.

What not to do: Don't let "the market exists" smuggle in "we can reach it." That conflation was the entire estate-organiser premise.

17. Zero on one instrument is not zero demand. Bing showed zero for a category whose Amazon competitors hold 24,700 reviews. The instrument was blind, not the market empty.

What not to do: Don't declare a market dead on one instrument. Bing said zero for a category with 24,700-review incumbents.

18. Every instrument has a blind spot — name it before using the data. Bing cannot see inside Amazon, Etsy or Pinterest.

What not to do: Don't use an instrument without naming its blind spot first.

19. Absence of competitors is a warning, not an opportunity. If a market exists and nobody serves it that way, ask why before assuming you're first.

What not to do: Don't treat an empty category as an opportunity. We nearly built big-button phone cards because nobody sold them. Nobody sells them because the free manual in the box wins.

20. Absence of a FORMAT in a proven market is a stronger warning still. Every top organiser is lay-flat; zero are perfect-bound. That's the answer.

What not to do: Don't ignore a missing FORMAT in a healthy category. Zero perfect-bound competitors was the answer, and we initially read it as an opening.

21. Review counts are an ordinal proxy for sales, not a count.

What not to do: Don't state review counts as sales.

22. BSR is the better proxy — and it's free and public.

What not to do: Don't ignore BSR when it's free and public — we spent a week without it.

23. Aggregator numbers ran 5× above primary sources every time we checked.

What not to do: Don't repeat an aggregator's number. Ours ran 5× above primary sources.

24. Grade every number: self-reported / platform-verified / estimated.

What not to do: Don't mix evidence grades in one sentence. A self-reported revenue claim and a platform-verified rating are not the same kind of fact.

25. A competition ratio alone is misleading. "Personalized gift" looks wonderful at 2.8:1 but Etsy itself rates its conversion "Very low."

What not to do: Don't order opportunities by competition ratio alone.

26. Ratio AND conversion rating together. Our bar: under ~25:1 with a High/Very-high rating. Two of twenty-five ideas cleared it.

What not to do: Don't skip the conversion rating when the platform gives you one free.

27. You cannot judge a bad number without a healthy benchmark. We had never seen a good Etsy number, so 25/month meant nothing until we had controls.

What not to do: Don't judge a number without controls. We called 25/month "bad" before we had ever seen a good Etsy number.

28. Marketplace search and web search are different populations. Someone typing the same term into Bing wants information; typing it into Etsy, they want to buy something.

What not to do: Don't glue a web-search volume to a marketplace standing. I did exactly that, told the CEO we'd "found it," and had to correct it an hour later.

29. Exclude yourself from your own analytics. Roughly half a 32-visit sample was our own verification loads.

What not to do: Don't count your own traffic. Half our 32 visits were our own checks.

30. When you check a live surface repeatedly, you appear in its numbers.

What not to do: Don't check a live surface repeatedly and then read its analytics innocently.

31. Measure from outside the account. Logged in as the owner, the marketplace showed us a #3 placement; logged out, #64.

What not to do: Don't measure your own visibility from your own account.

32. Free research beats paid research when you haven't got a product yet. Bing Webmaster keyword volumes, Meta Ad Library (what competitors PAY to advertise), Apple's review RSS feed, TikTok Creative Center — all free.

What not to do: Don't reach for a paid tool before exhausting free ones. We nearly justified $29/month while four free tools sat unused.

33. Ahrefs' connector needs a paid plan behind the OAuth — we recorded it as a free "unlock" and were wrong for days.

What not to do: Don't record a connector as a free unlock without checking what sits behind the OAuth. We propagated that error into our own source of truth.

34. Read three-star reviews, not one-star. One-stars are shipping complaints; three-stars are people who wanted to like it.

What not to do: Don't read only one-star reviews.

35. Unanswered questions in a listing's Q&A are a public list of the seller's blind spots.

What not to do: Don't skip the Q&A section — it's a free list of what the market wants and isn't getting.

36. What people dump in Buy Nothing groups reveals fast buyer's remorse.

What not to do: Don't ignore secondary resale/giveaway signals.

37. Comment-to-view ratio predicts a product about to sell better than view count.

What not to do: Don't chase view counts when the comment ratio is the predictive number.

38. The best single insight came from one stranger's four-star review — elderly parents refused a book because page one said "End of Life Planner."

What not to do: Don't dismiss a single review as anecdote. One four-star review gave us the most valuable product insight of the entire project.

39. Some markets live in closed rooms (county Facebook groups, trade association meetups, feed-store noticeboards) that no dashboard and no outsider can read.

What not to do: Don't conclude "nobody's talking about it" from public searches alone.

40. Empty search results can mean you're searching the wrong place, not that nobody's talking.

What not to do: Don't take empty Reddit results as evidence of absence.

41. Correctness is not the product. Our product was more accurate than every competitor and it sold nothing.

What not to do: Don't sell accuracy. We led with a correctness claim for two weeks. No buyer ever cared.

42. A quality claim is not a feature claim. Our headline claim was that our math was verified correct — true, unfalsifiable to a shopper, worthless in a listing.

What not to do: Don't make your headline claim one a shopper can't check.

43. If your superiority isn't visible to someone comparing two listings, it isn't a differentiator.

What not to do: Don't build a differentiator you can't show in a thumbnail.

44. Software dies to incumbents; printed goods have room. Six of seven app ideas died on a free or funded competitor. Card decks and ornaments didn't.

What not to do: Don't build consumer software as a small team. Seven ideas, seven free or funded incumbents.

45. A free incumbent with network effects is fatal. The category leader we'd missed was free, tightly specialised to our exact buyer, and handled coordination between coworkers.

What not to do: Don't enter a niche defended by a free product with network effects. We got three days into an app plan before we found it.

46. Check what the category actually monetises. The apps in the category we were entering charged for EXPORT, not for the core feature. The value was in getting data out.

What not to do: Don't assume the obvious feature is what the category charges for. They gave away the part we planned to sell and charged for the part we'd have given away — we'd have built the free half.

47. Print-on-demand may put your cost base above the market's price floor. A Printful tumbler lands at ~$31.86 against $7.95–19.99 bestsellers.

What not to do: Don't plan a physical product without landed cost versus market price.

48. The winners at low price points are not using POD. They own inventory.

What not to do: Don't assume competitors use your production method. The $8 bestsellers aren't on POD, which is why they can be $8.

49. POD works where printing is cheap relative to price: paper, cards, books. Not drinkware, not apparel.

What not to do: Don't put POD into drinkware or apparel at our scale.

50. KDP is the wrong manufacturer for anything people WRITE IN, and the right one for books people READ.

What not to do: Don't send a write-in workbook to KDP. The #1 organic result for the term we were chasing is that exact product, buried in the high six figures of its category's BSR.

51. The buyer is often not the user. Gifts, household purchases, anything bought for an aging parent.

What not to do: Don't write copy to the user when the buyer is someone else. Every line of our organiser copy addressed the person who'd never purchase it.

52. Clinical or morbid framing loses the sale at the kitchen table.

What not to do: Don't lead with mortality, illness or crisis in a consumer product.

53. Seasonal products have immovable deadlines and POD takes 7–14 days. Pre-sell weeks ahead or don't play.

What not to do: Don't plan a seasonal launch inside the POD lead time.

54. Teacher gifts and coach gifts are opposite markets — 79% of teachers prefer a gift card; coach-gift buyers want the object.

What not to do: Don't merge two audiences into one product because the words look similar. Teacher and coach gifts are opposite markets.

55. Prices are floors. Cut scope, never price.

What not to do: Don't discount to compete.

56. Set the price before the first view. Repricing a listing with history is worse than pricing it right cold.

What not to do: Don't set a price you'll want to change after launch.

57. The SKU with real per-order labour must not be the cheapest thing you sell.

What not to do: Don't price the labour-intensive SKU below the zero-labour one. We had custom-made at $24 against ready-made at $19.

58. Fee stacks are worse than they look at low prices. Etsy's flat $0.25 + $0.20 renewal makes an 11% fee an effective 17.8% on a cheap item.

What not to do: Don't ignore flat fees on cheap items.

59. Ship two formats off one build when it costs nothing — but only if each has a channel.

What not to do: Don't ship a second format without a channel for it.

60. "And also a PDF" is where the distribution problem gets waved past.

What not to do: Don't let "and also a PDF" stand in for a distribution plan. I proposed exactly that and was rightly overruled.

61. A digital download with no named channel is not a product, it's a file.

What not to do: Don't call a file a product.

62. Every bet passes the three-question screen: who is the buyer, can we reach them AND sell to them, and is there a wedge that isn't just who we are?

What not to do: Don't approve a bet before running the three-question screen. Board 016 approved five products without it; the screen later killed several.

63. The saturation test: never build what a competent stranger could replicate in a weekend with the same subscription.

What not to do: Don't build what an AI subscription reproduces in a weekend.

64. Distribution is the binding constraint, not product quality. Five routes blocked for five different reasons, all ending with "nobody comes."

What not to do: Don't keep fixing the product when the constraint is distribution. Five dead routes, five different causes, one shared symptom: nobody came.

65. A format is not a distribution plan. (2026-08-19, Board 019)

What not to do: research proved text was the right MEDIUM, then "post threads on X" slid in as if it were a plan — the same build-it-and-nobody-comes failure this business had already made five times, about to be repeated on a platform with no cold-start discovery pool at all.

How to do it right: name the mechanism that puts content in front of strangers before the first post. Our answer: a community platform as primary (communities ARE the discovery pool), replies into live conversations elsewhere (borrowed audiences), a long-form write-up venue monthly. Venue and mechanism, not just medium.

66. The best argument for a bet may not be in the proposal. (2026-08-19)

What not to do: pitch an idea on its surface appeal (trend, gap, funnel) without testing it against your own hardest screen.

How to do it right: the board carried the pivot 10-1 chiefly because it is the FIRST bet ever to pass question 3 of the three-question screen — the wedge is the operating log itself, which survives independent of who wrote it. Run your own screens on your own ideas before the board has to.

67. The agent that made the change never verifies the change.

What not to do: Don't let the builder check its own build. Four listings shipped with the wrong file attached because the same context reviewed its own work.

68. Adding is self-evidencing; removing is not. Observe the absence.

What not to do: Don't assume a removal worked. Every step looked done; the file was still attached.

69. A button that says "Subscribed" proves nothing. Reload, then read it.

What not to do: Don't trust a state label immediately after clicking. YouTube showed "Subscribed" on 13 videos and saved none.

70. A success toast proves nothing. Reload and observe the artifact.

What not to do: Don't trust a success toast.

71. Cache-bust every post-save check. A plain page load served hours-stale copies and produced three false "nothing landed" reports in one day.

What not to do: Don't verify with a plain page load. A stale cache produced three false "nothing landed" reports in a single afternoon.

72. An intermittently-correct check is worse than an obviously broken one.

What not to do: Don't trust a check that works most of the time. A title edit appeared to save instantly, which is exactly why we believed the method.

73. form_input can set a value the page never registers. Confirm the unsaved-changes indicator appeared before saving.

What not to do: Don't set a field and walk away. A title edit silently failed to register and published unchanged.

74. A dialog's "Done" may not save. The page-level Save must be clicked and confirmed greyed-out afterwards.

What not to do: Don't trust a modal's "Done". The visibility dialog closed cleanly and saved nothing.

75. Personalised search results flatter you. Any check of how the world sees you must come from a session the world would have.

What not to do: Don't check your own standing while logged in.

76. Give verifiers an environment brief — tab, auth state, expected wait times, retry instructions. Our first verifier reported a false failure by misreading a slow render as logged out.

What not to do: Don't send a verifier in blind. Our first one reported a false failure because nobody told it that back office renders slowly.

77. Spot-check by hand against a reference implementation, not against the generator that produced the output.

What not to do: Don't verify output against the generator that produced it.

78. Write fresh arithmetic to verify arithmetic. Never import the code under test.

What not to do: Don't import the code under test into the test.

79. Test suites that refuse to pass unspecified inputs are the only tooling we own that fails loudly.

What not to do: Don't build tooling that can't refuse. Everything except our test suite returned a plausible answer instead of an error.

80. Four dates and a first/last day beat a glance.

What not to do: Don't spot-check one date.

81. Four silent instruments in two days — stale cache, unregistered form field, non-saving dialog, personalised search. Assume a fifth exists.

What not to do: Don't assume you've found the last silent instrument.

82. "Nothing came in" and "I could not look" are different findings, and a monitoring report that merges them is worse than no report. (2026-08-19, inbox sweep)

What not to do: one platform returned a TLS "Privacy error" on every URL during a routine sweep — a repeat of the same network interception seen the day before. The tempting write-up is a clean "all surfaces quiet," which would have recorded an unchecked surface as a verified-empty one. A comment or DM sitting there for days would then look like it arrived from nowhere.

How to do it right: every monitored surface gets one of three states in the report — checked, empty · checked, here is what came in · could not check, here is why. Never let the third collapse into the first. And do not click through a certificate warning to force the check: on an intercepting proxy that trades a gap in the report for a compromised session, which is the worse of the two.

83. A third-party list or aggregator is not verification. It is a claim about the account, and it dies on the same live check every other claim does. (2026-08-19, engagement round)

What not to do: a prospecting pass listed a channel at 7.1K subscribers on the strength of a listicle site's roundup, and it went into the follow queue as verified. The live channel had 2 videos, both 17 years old, with 32 and 25 views, and no subscriber count even rendered on the page. The listicle's figure did not describe this channel at all — a familiar failure: treating a search-result artifact as proof an account is what it claims.

How to do it right: third-party numbers are a lead, never a verification. Open the profile, read what is actually there, and let the live page overrule the citation every time. The check cost one page load and stopped a follow that would have made us look like a bot padding a list.

84. Pick the model per task, never inherit. Haiku for mechanical and checkable, Sonnet for research and browser work, Opus for judgment.

What not to do: Don't inherit the main model by default. Mechanical work on Opus is money burned for no quality gain.

85. Anything with legal or reputational exposure gets the expensive model, however simple the task looks.

What not to do: Don't run a high-exposure question on a cheap model because the task looks simple.

86. A cheap model is fine when the output goes straight into a checker.

What not to do: Don't buy the expensive model for output that goes straight into a checker.

87. Brief agents adversarially: find the NO as hard as the YES.

What not to do: Don't brief an agent to confirm your idea. Neutral briefs produce agreeable findings.

88. Give agents the real artifact, never a description of it.

What not to do: Don't hand an agent a summary of the artifact. They review what you give them, and a summary hides the defects.

89. Tell them not to delegate. One agent spawned four sub-agents then ended its turn "waiting" and delivered nothing.

What not to do: Don't let agents delegate. One spawned four sub-agents, ended its turn "waiting," and produced nothing.

90. Instruct: if context runs short, report partial rather than nothing.

What not to do: Don't let an agent choose silence over a partial report.

91. Agents die on connection errors — resume from transcript rather than restarting.

What not to do: Don't restart a crashed agent from zero — resume it with its context.

92. Never predict a running agent's results.

What not to do: Don't report a background agent's likely findings. They're not findings until they arrive.

93. Dispatch independent work in parallel; queue only on shared resources.

What not to do: Don't serialise independent work.

94. Agents will honestly flag their own regressions if you ask for an honest read — one did, and it saved a bad deploy.

What not to do: Don't ask only "did it work" — ask for an honest read. The agent that caused a regression flagged it because we asked that way.

95. A subagent report is one lossy hop from the source. Verify load-bearing claims against the file.

What not to do: Don't act on a relayed claim without checking the file.

96. Name the standing constraints in every brief. Agents don't inherit your project's context file, so every rule you rely on has to be restated in the brief itself.

What not to do: Don't assume agents know the standing rules. We've had agents breach constraints written down in a file they were never given.

97. Tell them which tabs not to touch.

What not to do: Don't let an agent loose in a shared browser without naming the tabs it must not touch.

98. Convene it before the thing exists publicly, not after.

What not to do: Don't panel a product after launch. Post-launch feedback is a post-mortem.

99. Give each persona the real files, and tell them to find the reason it fails.

What not to do: Don't ask personas to be nice.

100. Weight the FINDINGS heavily and the VERDICTS lightly. Every genuine win was a bug, a defect, or a checkable fact. No vote ever did the work.

What not to do: Don't ship on a panel's vote. The unanimous "don't build the app" did no work; a free incumbent and an export-pricing finding did all of it.

101. A persona is a structured critique method, not a customer. It cannot tell you whether strangers will pay.

What not to do: Don't call a persona's approval market validation. It isn't a customer and it has never paid for anything.

102. Record kills by their finding, not their tally. "The niche is defended by a free network-effect incumbent" is reusable; "the panel voted no" teaches nothing.

What not to do: Don't record "the panel voted no." Record why.

103. Proportionality: a full panel for a launch, two or three for a small change.

What not to do: Don't run seven personas for a copy tweak — or two for a launch.

104. Diverse personas break the frame — age, buyer versus user, skeptic versus enthusiast. A panel of one type produces one type of idea.

What not to do: Don't build a panel of one type. Five people from the same world produce five versions of the same idea, which is the exact trap we were in.

105. Ask them what THEY would pay for in their own lives, not what they think of your idea.

What not to do: Don't ask personas to evaluate your idea when asking what they'd buy produces better material.

106. Reuse the same cast across products — they remember their prior complaints and check whether you fixed them.

What not to do: Don't use fresh personas every time — continuity is what caught our unfixed complaints.

107. The churned customer is the most valuable panelist. One persona quit two paid apps; why he quit was the entire product spec.

What not to do: Don't overlook the person who already quit a competitor.

108. Panels caught what our research missed every single time: a day/night gap, a printed dead-end, a free incumbent, a vocabulary wall.

What not to do: Don't assume your research beats a panel's eye. They found what four research agents missed, every round.

109. A panelist's confident bet is not evidence. One panelist's "no incumbent" certainty met a competitor with 55,300 reviews.

What not to do: Don't act on a panelist's confidence.

110. A board majority is an execution order, not a recommendation.

What not to do: Don't park a board majority on a task list waiting for the owner.

111. Give one seat a veto on the things that are unrecoverable if you get them wrong, and let it override any majority.

What not to do: Don't let a majority overrule the seat you appointed to stop you.

112. Some things aren't votable. Anything only the owner can physically do, and any standing ruling he's already made.

What not to do: Don't put the owner's own accounts, or a ruling he has already given, to a vote.

113. A later board supersedes an earlier one when it has better information — that's not conflict, it's sequence.

What not to do: Don't re-litigate a superseded decision — record which one governs.

114. Boards are wrong sometimes. One board costed a book at the wrong trim size and was 20% off on net margin.

What not to do: Don't assume the board's numbers are checked. Ours were from memory and 20% wrong.

115. Make the board flag its own soft numbers. Ours admitted its print costs came from memory, which is why we checked them.

What not to do: Don't let a board state a figure without flagging its source.

116. Every decision needs a tripwire — the observable that reverses it.

What not to do: Don't approve anything without the observable that would reverse it.

117. Ratify kills on paper so no future context re-litigates them.

What not to do: Don't leave a kill informal. Undocumented kills get rebuilt by the next context.

118. Put contradictions in front of the board rather than resolving them quietly in a status document.

What not to do: Don't resolve a board contradiction inside a status document.

119. Pre-register predictions before any experiment, with a decision table for every outcome written in advance.

What not to do: Don't run an experiment without writing the predictions first.

120. Amend a pre-registration BEFORE the data, never after. Amended after, it's just a story.

What not to do: Don't amend a prediction after the data lands.

121. Pre-register the confounders too — small sample, wrong season, no review base — so a null result isn't over-read.

What not to do: Don't omit the confounders — small sample, wrong season, no reviews — or a null result gets over-read.

122. A document that nobody opens fails silently. Put the re-read on a scheduler, not in a folder.

What not to do: Don't put a future check in a file and hope. Nothing errors when nobody opens it.

123. Write the anti-discard note for the future reader who'll say "that was the dead product line."

What not to do: Don't assume a future reader shares your context. They'll see a dead product line and discard a live finding.

124. State what an experiment can no longer answer. Once a confound is strong, a null tells you about the confound, not the original question.

What not to do: Don't keep claiming an experiment answers a question a confound has already spoiled.

125. Format winners are per-platform, not universal. One platform rewarded confessions 10:1; another rewarded the numbers and buried the confession.

What not to do: Don't generalise one platform's format winner. We did it twice — one platform's result became doctrine, and the other platform's data was the opposite.

126. One platform's result became false doctrine twice before we caught it.

What not to do: Don't reuse a winning post across platforms without checking it hasn't already flopped there. Our "winner" was another platform's worst performer.

127. Text on screen needs ~13 characters per second plus a lead-in.

What not to do: Don't set text timing by eye. Every beat looked fine and none were readable.

128. When a beat is too long, cut words — don't hold longer.

What not to do: Don't hold a beat longer to fix it. Cut the words.

129. Fewer beats beat shorter beats. Four, not sixteen.

What not to do: Don't cram sixteen beats into fifteen seconds.

130. Watch for the completion cliff — past ~16 seconds, drop-off rises.

What not to do: Don't ignore the completion cliff.

131. Decode HTML entities before counting characters.   counts as eight and silently inflated a timing by 1.6 seconds.

What not to do: Don't count characters without decoding entities.

132. Judge cadence in 30-post windows, never per post.

What not to do: Don't react to a single post's numbers.

133. Close the funnel in one hop: post → product. Every extra step leaks.

What not to do: Don't add a step between the post and the product.

134. Build topic playlists on every platform — free, no face required.

What not to do: Don't leave a back catalogue unorganised — playlists are free.

135. Never repeat the same phrasing across accounts in one session.

What not to do: Don't reuse phrasing across accounts.

136. New accounts get flagged for machine-pace activity. One platform suspended an account hours after a rapid profile build; another flagged it the same week.

What not to do: Don't operate a days-old account at machine pace. One platform suspended us within hours of a rapid profile build.

137. A VPN exit node looks like account compromise.

What not to do: Don't run brand accounts through a VPN.

138. Verify follows and subscribes by reloading. One platform accepted 13 subscribes and committed none.

What not to do: Don't assume follows committed.

139. Read the bio every time — an account name that looked exactly on-topic, with 362K followers, turned out on inspection to be a sports team.

What not to do: Don't follow an account on its name alone.

140. Post links in the reply, not the post — one platform throttles reach on links in the post itself.

What not to do: Don't put the link in the post on that platform.

141. Don't build everything AI-generated when platforms gate AI content. Platforms require disclosure of AI-generated media, and checked boxes can limit reach. Prefer content shapes that don't trigger the requirement at all — text, real screenshots, screen recordings of actual work.

What not to do: Don't default every post to AI-generated media and then wonder why reach is throttled by the disclosure checkbox you're forced to tick.

142. When something IS synthetic media, mark it every time. A throttled post costs a little; a banned account costs the channel. Compliance beats reach whenever they conflict.

What not to do: Don't skip the AI-content disclosure to protect reach. That trade is how accounts die — and we already lost days to two platform suspensions for lesser flags.

143. The honest format and the safe format can be the same format. Mistake content built on real screenshots and logs of things that actually happened is simultaneously the most credible shape (checkable claims) and the disclosure-safe shape (nothing synthetic to declare). When integrity and platform mechanics point the same direction, that's the direction.

What not to do: Don't reach for synthetic polish when real evidence exists. Our own screenshots of real failures are more credible AND safer than anything generated to look good.

144. Rescind rules that stop ideas; replace them with postures that guide judgment. "Never mention AI" blocked an entire venture. "Be mindful of what triggers disclosure, and mark what requires marking" enables the same venture safely. A ban is brittle; a posture travels.

What not to do: Don't write absolute bans where a judgment posture would serve. The never-mention-AI rule sat unexamined until it collided with the best idea we'd had — a rule that blocks thinking outlives its reason.

145. Don't let a correction harden into the doctrine it corrected. (2026-08-19, pipeline session's own flag on its own finding)

What not to do: "one platform rewards confessions, another rewards the numbers" was built from 11 posts with one outlier versus 12 posts topping at 562 — two data points. The finding existed to stop one platform's result becoming doctrine, and it was itself about to become doctrine — e.g. refusing to ever test a confession format on the platform that hadn't rewarded it yet.

How to do it right: label small-sample findings as priors to test, not rules to obey — in the record, next to the finding, by the person who made it. Log predictions ("this format is mechanism-shaped, so it should fit here too") and let results grade them.

146. Adapted-per-surface and cross-posted look identical on a task list and are not the same thing. (2026-08-19)

What not to do: fifteen uploads in one day, the identical asset on each platform, results diverging 7× and teaching us nothing per surface.

How to do it right: one lesson, four SHAPES — a community post, a thread, a short card, a site page — each built for its surface's mechanics. Every content brief states which shape, not just which lesson.

147. Before commenting, check whether we have already commented. The comment count includes our own, and two near-identical comments from one account under one video is the clearest bot signal there is. (2026-08-19, engagement round)

What not to do: I opened a video, read "Comments 1", took that 1 to be a stranger's, and posted a comment opening with the same personal claim we'd used the day before, on the same video, under our own prior comment. Same account, same video, same opening line, one day apart. I had carefully checked the like state on that video (the notes said it was already liked) and never thought to check the comment state.

How to do it right: on any item we may have touched before, check every interaction type, not the one the notes happen to mention. Deleted the duplicate and reload-verified back to 1 comment. The "no repeated phrasing in a session" rule needs a sibling: no repeated substance across sessions, on the same item.

148. A reply drafted in a previous session is a draft, not a decision. Re-read it against the live thread before sending. (2026-08-19, engagement round)

What not to do: our notes carried a fully cleared reply for an owed thread, and the obvious move was to paste it. Its middle sentence restated almost word for word something we ourselves had already posted 22 hours earlier, answering the same underlying point. Sending it would have answered their new point by repeating our old one.

How to do it right: read the whole thread first (already the rule), then check the draft against our own prior turns as well as theirs, and rewrite to answer what they actually added. Theirs had added new specifics we hadn't addressed yet, so the reply went to that instead.

149. A site generator that wipes its output directory will delete hosted files. Keep an assets folder it copies in on every build.

What not to do: Don't put a hosted file in a directory your generator wipes. The CEO hit a dead link because a rebuild silently deleted his video.

150. Content-Disposition: attachment turns a link into a download — the only way to get a video onto a phone from a remote session.

What not to do: Don't send someone a link they can't save from a phone.

151. Cloudflare prefers extensionless URLs and 308-redirects to them.

What not to do: Don't assume a URL resolves as written.

152. Headless Chrome renders HTML to PNG and PDF with no design tool, no account, no watermark.

What not to do: Don't reach for a design tool you have to sign up for.

153. Fixed-height overflow-hidden page boxes keep PDF page counts exact.

What not to do: Don't let content flow freely if page count matters.

154. pdfinfo for page count, pdftotext for content, sips -Z for thumbnail legibility. All free, all local.

What not to do: Don't eyeball a PDF's specs.

155. Compress video before upload — bridges cap around 10MB and a 13MB file silently fails.

What not to do: Don't upload an uncompressed video and call the failure mysterious.

156. Non-greedy regex for nested markdown. [^*]+ broke on bold containing italics and left literal asterisks in a board document.

What not to do: Don't write greedy regex for nested markup. It ate the most important quote in a board document.

157. Join hard-wrapped lines before parsing inline markup.

What not to do: Don't parse hard-wrapped markdown line by line.

158. A transparent background parameter was load-bearing — an opaque one produced three rounds of black video frames.

What not to do: Don't debug a rendering bug three times without checking the background parameter.

159. The system clock is authoritative. A carried-forward date corrupted a day of records and scheduled two videos a day late.

What not to do: Don't carry a date forward. A wrong date corrupted a day of filenames and scheduled two videos a day late.

160. Rename misdated files rather than leaving them — the filename is what a future context trusts.

What not to do: Don't leave a misdated file in place — the name is what future contexts believe.

161. Test both branches of a fallback before trusting either. (2026-08-19, voice-render pipeline)

What not to do: a voiceover script preferred a real recording over text-to-speech — and the real-voice branch silently never fired, because pipefail made the file-detection pipeline fail whenever any candidate extension was missing. The TTS test passed, so the script looked done. One deliberate test of the other branch caught it in thirty seconds.

How to do it right: a script with an if/else has two behaviours; exercising one proves half the script. Feed it an input for each branch before calling it built — especially the branch you expect to use later rather than today.

162. A platform's limit usually attaches to the identifier, not to the account — so deleting the account doesn't reset it. (2026-08-19)

What not to do: blocked from creating a new email account because the phone number hit the provider's per-number cap, the instinct was to delete the existing brand account to free the slot. It would not have worked — the cap follows the phone number and decays on time — and it would have destroyed a linked video channel, a marketplace login and the recovery point for four brand accounts.

How to do it right: before deleting anything to "free up" a quota, ask what the quota is actually keyed to. And route around the gate instead: buying a domain first and turning on free email routing gave a working, phone-free brand address for $0 — better-looking on signups than a free webmail account, and it never needed the blocked resource at all.

163. Order operations by what unblocks what, not by what feels foundational. (2026-08-19)

What not to do: the registration runbook put "create the email" first because email feels like the foundation. Email was the one step that was blocked; the domain — which nobody had marked as a dependency — was what made a free email possible.

How to do it right: when a step blocks, check whether a later step in the list actually supplies what the blocked one needs. Re-sequence rather than wait.

164. Don't wait for approval on majority-approved work. "Why would you wait for me to tell you" was a correction worth taking.

What not to do: Don't ask twice. "Why would you wait for me to tell you" was earned.

165. Ask once, get a durable ruling, never ask again. One question that produces a written rule is cheap; the same question twice is expensive.

What not to do: Don't ask a question you could turn into a permanent rule.

166. Flag the ask, then act — don't hold the turn open waiting.

What not to do: Don't hold the turn open waiting on an answer.

167. Never sit idle when the browser or filesystem is free.

What not to do: Don't idle while a background agent runs.

168. Run parallel pathways — information per owner-hour is the metric.

What not to do: Don't run one experiment at a time when the constraint is his hours, not our capacity.

169. Report failures plainly. An upload failed four times; saying so was worth more than hiding it.

What not to do: Don't soften a failure. The upload failed four times and saying so plainly was worth more than a workaround narrative.

170. Lead with the outcome, not the process.

What not to do: Don't bury the outcome under the process.

171. His five to ten fragmented hours are the scarce resource. Anything requiring scheduled or live presence is structurally impossible.

What not to do: Don't propose anything requiring live or scheduled presence.

172. A 35-minute account signup unlocked more than a week of building.

What not to do: Don't spend a week building when 35 minutes of his time unlocks more.

173. He is right more often than the analysis when he says something feels wrong. His instinct that our target customers already had their own solution preceded the data proving it by a day.

What not to do: Don't argue with his instinct before checking it. His read that the target customers already had their own solution was right a full day before the data proved it.

174. Consent does not transfer between sessions. Approval given in one chat is not authorization in another.

What not to do: Don't treat approval in one chat as authorization in another.

175. Never route a declined action to another session. That's laundering, even when the action is right.

What not to do: Don't pick up an action another session declined. However right it looks, that's laundering.

176. Verify relayed rulings against the file, even from a trusted peer.

What not to do: Don't act on a relay without checking the source file.

177. Single-holder resources need announcing and releasing — the browser, a shop's back office, a shared build file.

What not to do: Don't take a shared resource silently. Two sessions nearly edited the same shop simultaneously.

178. Adversarial cross-checking between sessions caught what neither found alone — a wrong bug diagnosis, an ethics breach in a title, a bad thesis, and an over-claim.

What not to do: Don't run a single session on a decision that matters. Every serious error that day was caught by the other one.

179. When two sessions reach the same finding by different paths, it's a rule, not a coincidence.

What not to do: Don't dismiss a finding two paths reached independently.

180. A peer's correction of your best idea is the most valuable message you will get.

What not to do: Don't defend your best idea when a peer finds the flaw. A two-format fix was elegant and wrong.

181. Nothing has been validated by a real buyer. Zero sales. Every rule above is a rule about avoiding waste, not a rule about making money.

What not to do: Don't call any of this validated. No stranger has paid us anything.

182. We got faster at killing bad ideas long before we got good at finding good ones.

What not to do: Don't mistake a good kill rate for progress. We got excellent at not wasting money and have not yet made any.

183. Twenty-three ideas died on evidence in one night; two survived. That ratio is probably normal and should be expected, not mourned.

What not to do: Don't mourn a high kill ratio — 23 of 25 is probably normal.

184. The machine works. The audience doesn't exist yet. That is the whole remaining problem.

What not to do: Don't build another product to fix a distribution problem. That's the reflex this business reaches for every time, and it has failed five times in a row.

185. A working fix is not a diagnosis of what broke.

What not to do: Six browser-based upload attempts failed with no explanation, back to back, on one platform. We rewired posting through a different route (a direct API) instead of finding the cause, and it worked twice in a row. We logged the new route as fixed and moved on — but we still do not know why the original route failed, so if the new one ever breaks too, we have no diagnosis to fall back on.

186. Measuring a platform with an instrument that never touches it invents a crisis that isn't there. (2026-08-22) Before reporting that a surface is dead, confirm the tool you measured it with is the tool that actually publishes to it.

What not to do: counted zero YouTube entries in a posting tool's own listing command, and reported three separate times that YouTube had never received a single post — calling it the most serious gap of the night because YouTube is the evergreen, searchable surface. That tool was never wired to publish to YouTube in the first place. Zero was the guaranteed output of the wrong question, not evidence of a broken channel. This is the same defect class as our health-checker failure — the instrument lied, the system was fine.

How to do it right: give every platform its own named instrument instead of trusting one shared tool for all of them. Some surfaces are checked through the posting tool's own listing command; YouTube publishes through a different route entirely and needs its own marker file checked directly. YouTube, checked the right way, turned out to be the healthiest surface we had that night — while being reported as the most broken.

187. Fixing a generator does not fix the artifacts it already generated. (2026-08-22) A source fix and a rendered artifact are two different objects. Patching the first does nothing to the pool full of the second.

What not to do: a caption-generator defect — mangled apostrophes, wrongly title-cased headlines — was correctly fixed at source and reported as fixed. A post already rendered under the old, broken code went out anyway: the post went out a good half hour before the caption file was regenerated. It was then reported to the CEO as a regression, which it was not.

How to do it right: fixing a generator creates a stale-artifact obligation — every package already rendered by the old code is now suspect. Either regenerate all of them in the same session, or record which packages predate the fix so the poster skips them. Checked after the fact: the regenerated caption files on disk were clean; the typo existed only on the one post that had already gone out before regeneration finished. A couple of direct checks settled this in minutes; guessing had already produced a wrong report to the CEO.

188. macOS privacy grants bind at process launch, so the toggle is never the fix — the relaunch is. (2026-08-22) Granting Full Disk Access to a running app changes nothing for that running app. Only a fresh launch reads the new permission.

What not to do: access was granted and confirmed granted, and the block stayed in place — re-tested repeatedly across several exchanges before the actual cause was named. Time was also lost diagnosing it as a filesystem problem: normal permissions and no ACLs looked like it ruled the privacy system out entirely. It didn't.

How to do it right: the signature of a privacy-permission denial is unmistakable once you know it: metadata reads fine, opening the file fails; files the process created itself work (they carry the OS's own provenance tag), while pre-existing ones don't; and the block follows the protected location, not the disk — one folder inside the home directory read normally while the standard Desktop and Documents folders returned "Operation not permitted." Walk the process tree to find the actual responsible app before telling anyone which entry to grant — the real parent process was not the one already sitting in the permissions list, but a similarly-named nested helper. Grant both, then fully quit and reopen the app. Toggling the permission alone never reaches a process that's already running.

189. TikTok's Content Gap "Suggested" tab shows consumer demand, not your category's — search your own terms instead. (2026-08-22) A discovery tab answers "what is the broad audience under-served on" — it never answers "is there demand for what I make."

What not to do: read roughly a hundred Content Gap terms off the Suggested tab — kittens, dogs, lip sync, hair extensions, collagen, motivational quotes — and concluded that search demand for our niche was effectively zero, then rebuilt the whole strategy around that, demoting the platform to a watch-time-only surface.

How to do it right: the platform's own Creator Search Insights tool takes a typed term and returns its real volume. A handful of direct searches reversed the conclusion completely: our core term alone returned millions of views across more than a dozen distinct human phrasings, with one related query up several hundred percent. The Suggested tab had been the wrong lens, not the wrong platform. This sits beside "ask the platform what it knows before building for it" — but adds the corollary: ask it about YOU, not about everyone. The general feed of a discovery tool describes the general audience.

190. Aggregate labels and long-tail queries look identical in a keyword tool, and only one of them is targetable. (2026-08-22) When a search tool returns huge numbers in a tight growth band with machine-shaped phrasing, those are category aggregates — not things a human typed.

What not to do: treat a broad category label showing millions of impressions as millions of people literally searching that phrase. Nobody types it. The tell is that every such entry clustered tightly inside the same narrow growth band — real human search growth scatters; these numbers didn't.

How to do it right: aggregate-only vs. long-tail is a read on whether a term is actually yours. A term returning only aggregates is mass-consumer and saturated, with no niche intent to aim at — the single most famous term in our category produced only a handful of real human queries. A term returning many distinct phrasings with varied growth has a real practitioner niche behind it — our own core term produced well over a dozen distinct queries totaling several times the targetable volume, despite being far less generally famous, because the famous term's volume is almost entirely absorbed into aggregate clusters. Count the distinct human phrasings, never the biggest number on the screen.

191. A verification tool is for people who don't read the code — and that's a larger audience than developers, not a smaller one. (2026-08-22) Need is highest where the capability to check is lowest.

What not to do: aim verification content at experienced developers because they are the obvious "serious" audience for AI-agent tooling. They are also the audience that already reads the diff and catches a false "task complete" unaided — the audience that needs the product least.

How to do it right: a verification tool is for people who don't read the code. That is not a smaller audience than developers — it is a larger one, and it is the one with the actual problem. A term for people building software with AI without reading the code returns roughly 1.24 million in targetable search demand on one platform, headed by a query up over 260%. Two bridge terms that combine the AI-coding angle with that same term carry real demand of their own and connect both audiences. Never target the bare word stripped of context — on its own it returns an entirely different, larger, unrelated audience: a chat app, a daily check-in ritual, a hairstyle, and unrelated video-editing trends, all with far bigger numbers than the audience actually worth targeting.

192. Nobody in this niche has a verifiable cold-start track record, including the people selling courses about it. (2026-08-22) When every "case study" in a space traces back to someone selling a playbook, the honest conclusion is that the evidence doesn't exist — not that you searched badly.

What not to do: plan the first thousand followers by copying a documented faceless-content account's early posts. A growth research pass went looking for a credible, checkable example and instead found this: every cold-start case study we could find traced back to someone selling a playbook, and none of them carried follower history, view counts or dates. Every "10K in a couple of months" / "100K in under a year" figure traced back to a site that sells faceless-content tools or courses — every source had a direct financial interest in the number sounding achievable. Same for the algorithm multipliers everyone repeats — save multipliers, completion-rate thresholds — no primary source, suspiciously round, quoted verbatim across sites that cite each other.

How to do it right: separate DIRECTION from MAGNITUDE. Direction is defensible — Instagram's own Adam Mosseri has publicly named watch time, shares and saves as the platform's top ranking signals, with likes now weakest. Magnitude is folklore. Build on the two things that are independently checkable — platform-reported search demand, and what the platform itself says it ranks — and let your own logged results close the loop from there. This is the same discipline as "a keyword is not a product": check the thing itself, never a number about it.

193. People save a reference, not a reflection. (2026-08-22) A save is a bookmark — someone marking "I will need this again." Content earns it by being retrievable, not by being enjoyable.

What not to do: keep publishing narrative "here's what I learned" posts and wonder why they produce views and no saves or likes at all. There's nothing in a reflection to come back for. Nobody bookmarks a feeling.

How to do it right: ship posts as reference objects — the exact prompt, the exact setting, the specific before/after, the numbered checklist, the one line that fixed it. The test: would someone screenshot this BEFORE they needed it? A lesson log like this one already contains this material in the right shape, so turning it into reference posts is a reformatting change, not new production cost. Given saves and shares outrank likes as ranking signals on the platforms that matter here, this is also the cheapest available lever on distribution.

194. A costed assumption in your own doctrine decays silently — re-check before relying on it. (2026-08-22)

What not to do: plan a comment-to-DM funnel against a free-tier contact limit recorded in the figure we had recorded. As of August 2026, a platform overhaul had already cut that free tier by a factor of forty, to 25 active contacts — meaning one moderately successful comment-to-DM post now exhausts it the same day it goes up.

How to do it right: the paid entry tier remains the correct fallback — as of August 2026, roughly $14/month for 250 contacts — and is still the sanctioned route once manual fulfilment DMs outgrow hand-sending: approved via the platform's own API, low risk inside its messaging window. Budget for it from the first successful codeword post, not after the free tier fails mid-campaign.

195. A caption track you promised to turn off may not exist as something you can turn off — check before promising it. (2026-08-22)

What not to do: a stakeholder flagged a YouTube Short where the platform's own caption track rendered a black-boxed transcript directly on top of our burned-in text, saying the same words twice. It was reported back as fixable — "disable the auto-generated caption track in Studio" — and a step was added to the posting routine on that basis. Then Studio was actually opened: every one of our videos showed zero caption tracks listed. There was nothing to disable, because it's generated live at playback, not stored as a file.

How to do it right: two things are true, and neither is "turn it off." First, a hard rule that every video's voice reads its on-screen text verbatim guarantees this collision permanently — the platform's own speech recognition will always reproduce words that are already being read aloud. Second, the real workaround — uploading a near-empty caption file to override the platform's automatic one — strips captions from deaf viewers to fix a cosmetic overlap for hearing ones, so we don't do that. The correct fix is layout: keep burned-in text clear of the band where the platform renders its own captions, accept the overlap for viewers with captions on, and note that the content is already fully legible without them. Recorded rather than "fixed" — and the routine step added on the wrong premise was removed.

196. A regex that strips suffixes invents duplicates — verify a checkable number before acting on it, no matter who asserts it. (2026-08-22) The same wrong-instrument failure that can bite a build can originate in adversarial review itself.

What not to do: an adversarial review returned a blocking tripwire asserting that a long numbered log contained twenty-two duplicated entry numbers. It contained one. The false count came from a check that matched only the leading digits of each entry's label, so every deliberately-lettered variant and addendum already in the file collapsed into a false collision. The first check run to confirm it used that same pattern and reproduced the same wrong answer — which is exactly why it looked confirmed.

How to do it right: match the whole label, not just its numeric prefix. Matching the full label instead of only the leading number showed the file was exactly as sound as it looked: dozens of distinct, correctly-labeled entries, and exactly one genuine collision, where two separate entries had mistakenly been given the same number. That one was fixed by giving each a distinct letter suffix, following a convention already used elsewhere in the same file for exactly this situation — never by renumbering. The blocking tripwire dissolved on inspection. Adversarial review is not exempt from verification; it is where an unverified number does the most damage, because it arrives with authority already attached.

197. At thumbnail size only the headline has to survive, and it does. (2026-08-22) Test legibility at the size where the decision is actually made, and be clear about WHICH element has to win there.

What not to do: a focus group measured that a rebuilt brand lockup's tagline was an unreadable smear at small grid-thumbnail sizes — the real sizes where someone decides whether to tap a short-form video — and ranked it a defect on the theory that "the design effort fixed legibility for someone already watching, not for someone deciding whether to tap." Correct measurement. Wrong conclusion about what it implies.

How to do it right: downscale an actual rendered frame to real grid sizes and look. At every size tested, the HEADLINE stayed cleanly legible; the wordmark held up as a recognizable shape at the larger size and blurred at the smaller one; the tagline was gone at both. That's the correct outcome, not a failure — a tagline has never been what earns a tap. Auto-fit type sizing means a short hook renders large enough to read at one-tenth scale, which is exactly the property thumbnail legibility needs. The actionable version of the finding is therefore narrower than first stated: keep hooks SHORT, because auto-fit is what buys thumbnail legibility, and a long hook shrinks the type until it stops surviving the downscale.

198. "Something went wrong" on two different platforms at once is a symptom of your own browser, not their servers. (2026-08-22) When two unrelated services fail identically in the same session, stop diagnosing the services.

What not to do: logged a platform's own profile tab returning the same generic error message three times across several hours as a platform-side problem worth escalating — while the CEO was simultaneously watching those same videos play fine on his phone, with view counts ticking up. The account was never the issue.

How to do it right: within minutes of that, a second, entirely unrelated platform's own studio interface returned the same generic error in the SAME browser profile, and the first platform's own avatar had also failed to render, showing a grey placeholder instead. Three content-loading failures, three different surfaces, one browser. This was the same profile we had already recorded as having a broken media pipeline — the bug that had killed browser-based uploads and forced a move to a direct posting API. Our own browser is an unreliable instrument for verifying that content is live, and it had been generating phantom platform incidents. Verify live state from an API, from marker files, or from a phone in hand — never from this browser alone. A correlation was also noted, not yet proven: both failures happened while a heavy render batch had the machine under very high load, and we already knew renders starve other work. Whether the cause was the render load or the browser profile itself, the rule is the same: never run browser-based verification while renders are running, and never conclude a platform is broken from this browser alone.

199. pgrep is not a lock, and the gap between two jobs is exactly where the race lives. (2026-08-22) "Wait until no process of type X is running" is not mutual exclusion. It's a poll with a hole in it, and the hole is the moment a batch finishes one item and starts the next.

What not to do: serialize renders with a loop that polls for a running process and sleeps in between. A follow-on queue polled during the brief gap between two items inside a running batch, saw nothing running, and started its own render. Two renders then ran concurrently, spawning well over a dozen headless browser processes and driving system load past double what had already killed several subagents and posting cycles the day before. We had already logged the render-starvation lesson about exactly this failure, hours earlier — then rebuilt the same failure with a different mechanism. Worse, a third queue was armed with the same racy loop, one poll away from tripling it.

How to do it right: use an atomic primitive. A directory-creation call either succeeds or fails outright — there's no window between checking and taking:

LOCK=/tmp/render.lock
while ! mkdir "$LOCK" 2>/dev/null; do sleep 15; done
trap 'rmdir "$LOCK" 2>/dev/null' EXIT INT TERM

Two other rules learned in the same cleanup: back up an artifact before re-rendering it and restore that backup if the render is interrupted or a quality gate fails — a killed render leaves a truncated file where a good one used to be — and a killed render must leave its hold marker in place, so an interrupted job can never silently become postable. The guard that saved this was a stale-artifact hold written earlier that same hour: the package in question was mid-render when killed, and could not have posted regardless.

200. cp updates mtime, so a restored backup looks fresh while carrying old content. (2026-08-22) A timestamp says when the bytes were written, never what the bytes are. Any staleness gate built only on mtime can be defeated by an ordinary file copy.

What not to do: trust a stale-artifact gate on its own. After killing an interrupted render, a video file was correctly restored from its pre-render backup — the right recovery move. But the copy operation stamped the restored file with the current time, so a gate comparing that file's timestamp against the renderer's now read it as freshly rendered, when its actual content was the old version, predating a recent brand-lockup update.

How to do it right: pair the cheap mtime check with a CONTENT check and require both. Our own brand-consistency checker compares the first frame against the current lockup reference and returned a lockup-difference score more than double its own failure threshold — an unambiguous fail, because the restored file genuinely carried a different, outdated brand mark. The hold stayed on. mtime is the fast filter that decides what to inspect; the pixel comparison is what actually decides. When restoring a backup over a gated artifact, either re-render it or preserve the original timestamp on the copy so the cheap filter still tells the truth.