✿ Unified morning report

Question 53 asked to put the main folder back on main. Someone did that at 1:54 PM on September 25. But everything saved while the folder sat on the Codex branch stayed on that branch: the night notes of September 23, 24 and 25, question 53 itself, and the evidence, run record and ads digest from each of those three mornings. Twelve saved pieces of work in all.

So your morning page no longer shows question 53, and GitHub's copy still ends at September 22. Nothing is lost; all twelve are on this computer.

I checked that copying them onto main is safe: none of the twelve touch any file with someone's unsaved work in it, or any file the Codex session changed. When I tried, the session's permission guard stopped it as a change to shared history. That is a reasonable line, so I stopped too.

What I need from you: a yes, in a sitting, to copy those twelve onto main. The Codex session's own theme work stays on its branch. It is about five minutes. The exact steps are backlog item NS-155.

The storefront review on September 25 left a whole Microsoft Edge profile (182 MB) in deliverables/storefront-research/edge-audit-silence/. A browser profile holds the browser's saved-password, cookie and form-fill files. I did not open them.

It was not on the website, and the morning's automatic save would not have picked it up, because that save takes only a named list of files. But nothing stopped a hand-typed "save everything" from sending it to GitHub for good.

It now cannot: a small rule file beside it tells git to ignore that folder, and git confirms it does. The folder itself is where it was; whoever made it can delete it when they are done with it.

The last booked email sends on September 30, and the reward codes run out on the same day. Question 5 (the reward rule) and question 50 (push the three written October emails as drafts) are still the fix.

On September 24 and 25 a session wrote a store product repair list, a list of product-picture changes, a monthly collections review, a storefront sales review and more of the October–November email plan. None of it is saved yet. It is that session's open work, so I did not save, move or change any of it. Ten ads records from September 21 are still unsaved in a second copy, G:\knowledge\iris-03a-component-tracking, as they have been every night since.

This list is one campaign, not the whole account. These verdicts cover 20_ABO_TEST_10.07.2025, our dedicated test campaign, and that is deliberate — the rest of the account is judged on its own cycle rather than every morning. Over the seven days to Sep 25 that these verdicts judge, 10 more ad sets in 2 other campaigns spent $1,077, against $0 inside this one. Nothing on this page gives any of that a verdict, and nothing here says it is fine. The verdicts for the rest of the account are on the daily ads digest, https://iris-reports.pages.dev/daily/, dated Sep 22 — that copy is 4 days old.

These rows are read from the nightly scan file and change nothing. Tim still makes every decision, and switches anything on or off only in Meta.

These are Meta’s own figures, read from our copy of them. Reading them changed nothing.

A full Inbox reconciliation. It wrote 1 draft for Tim to send, filed 30 threads and moved 35 to the recoverable bin, leaving 15 threads in the Inbox. Nothing was sent; Tim sends every reply. 1 other receipt in that folder is written in a wording this page cannot read, so it is named here and not counted.

No customer-service run has left a receipt since, so the 15 threads that run left in the Inbox are the count from that morning, 7 days ago — not a count of what is waiting today.

There is no automatic ticket count on this page because the 6:45 job stopped sorting the mail on August 12, when customer service became an attended run. That is a decision, not a fault. What you are reading is the run's own receipt, which records counts and states and never a customer.

Read this first, because it was wrong of me to tell you nothing could start without you. Your answer here cannot take a reward away from anyone — it can only add people and raise amounts. The rule as written reads an order's total after store credit; flipping it reads the total before, and a before-discount total is always the larger of the two, so a customer who qualifies under the rule as written still qualifies after a flip, and their tier can only go up. So 19 of the 21 people we identified on August 28 get exactly the same thing whichever way you rule. What your answer actually decides is narrower than I have been saying: whether nine more people join the thank-you list, and whether two of the 21 get $25 instead of $10. That is $120 and eleven rewards, not the whole program. I treated a fairness question as a gate on all thirty rewards when it gates eleven of them, and that is part of why twenty-one people who were promised a credit in early September have had nothing. Proof, with the two lines of code it turns on: docs/email/question-5-was-never-a-blocker-for-19-of-the-21-2026-09-13.md. What I still cannot do on my own: creating the discount codes is a write to the live store and pushing the email is a write to Klaviyo, and neither happens unattended — and I never schedule and never send, which does not change. Background, written September 12: Read this part first, because it is no longer only a fairness question. On August 11 we told the list that any single order of $60 or more in the first eleven days of August would get a store credit in September, and $100 or more a gift card, with — our words — no code to remember and nothing to claim. Twenty-one people qualified, and not one of them has been sent anything. No codes exist in Shopify: the September run produced a plan and a read-only collision check, never a creation. The email that keeps the promise was written on August 28 and has never been pushed to Klaviyo. The codes the plan reserves run to September 30, and the September 26 reminder email is written against that date. Nothing is lost yet and nobody has complained. The whole program was still deliverable when this was written on September 12: your answer below, then codes created, then the thank-you email built and pushed for you to schedule. It is late, not gone. Why it stopped here: this question decides how many codes exist, so nothing downstream of it could start. That is the honest reason, and it is also why a fairness question dated September 1 turned into a promise sitting unkept. Due: 2026-09-01, and answered with numbers rather than a shrug. The August 1 to 11 report ran on 2026-08-28 and I computed it both ways. After discounts, the rule as written: 21 people, $330. Before discounts, if you flip it: 30 people, $450. The nine extra people bought $65 to $98 of shirts and paid with credit we had given them, which took them under the $60 line; two more move up from the $10 credit to the $25 gift card. So the flip costs $120 and adds nine of our better customers to the thank-you list. I do not have a technical recommendation because this is not a technical question, it is a fairness one, and the plainest way to put it is that the August 11 email thanked people for what they spent, and those nine spent it. The change is one line in build-qualifier-report.py and a rerun of two scripts, about five minutes. Evidence: jobs/email/rewards/september-2026-run-log.md sections 4 and 5; jobs/email/rewards/september-2026-code-plan.public.json, whose 21 rows carry advertised_end September 30, 2026; jobs/email/rewards/september-2026-email-brief.md, written 2026-08-28 and never pushed; and our copy of Klaviyo's sends, which records no reward email between August 25 and September 10.

Rewritten again 2026-09-18 — you can answer this "no" and lose nothing, because the thin week fills itself from emails that are already written. The version below offered to write two new emails into the next thin week. Read against the booked calendar on 2026-09-18, that offer is not needed. The week your cockpit names as thin is the week of Monday September 21. It holds two booked sends, Tuesday the 22nd and Thursday the 24th, against your target of three — and the third already exists: the September 26 credit reminder, written, fact-checked, and waiting only on question 5. Push that one and the week is at three without a word being written. The week after it, Monday September 28, is the same story: two booked, Monday the 28th and Wednesday the 30th, with the October 2 and October 4 emails already written and waiting on question 50 — which would put that week at four. So the whole of your remaining calendar reaches target on emails that exist. What a yes here would buy is new writing nobody needs; what answering 5 and 50 buys is the same weeks filled from work already done. One thing the version below got wrong, and it is worth naming because this note was rewritten two days earlier to stop exactly this. It said "the thin week is the one you are in" and "nothing further is booked between now and Sunday". Both were untrue when written: the week you are in runs Monday September 14 to Sunday the 20th, it does not contain the September 10 send that sentence rested on, and it has two booked sends in it — Friday the 18th and Sunday the 20th. The rewrite took the counts out of this note to stop them going stale and then put a count back in as a sentence. Dates are used here instead, read from the same morning pull the cockpit reads, and the counts still live only on the cockpit's email card. The earlier rewrite is kept below, unchanged. Rewritten 2026-09-16 — this question was asking you to do something that had stopped being possible. It offered to write two emails into the week after your surgery so they were ready before you went in. That week was September 7 to 13; it ended on September 13 having sent one email, and nothing can be added to a week that has finished. The ask has been pointed at the next thin week instead, which is the same offer aimed somewhere it can still land. What the week actually was, and it is now a closed fact rather than a moving count: one campaign sent, on September 10. The live week-by-week counts stay on the cockpit's email card and nowhere else, for the reason written below. Due: 2026-09-06, because after that the week has started — and it now has. Still worth answering, and here is what changed by waiting: the thin week is the one you are in, and its single email — September 10 — has now sent, so nothing further was booked between September 12 and Sunday, September 13. A yes now means two emails written for you to read and schedule inside the week of September 7 rather than ahead of it, which is a smaller and later thing than what this question originally offered. The week-by-week counts have been taken out of this note on 2026-09-12, and here is why. Twice this note has carried a booked total typed on the night it was written — eleven on September 1, nine on September 8 — and both times the total went stale the moment you sent the next email, so your cockpit and this ledger disagreed about the same thing on the same morning. It happened a third time in the week of September 7: the September 10 send took the total from nine to eight and this note still said nine. The counts now live in one place only — the email card on your cockpit, which is rebuilt every morning from the read-only Klaviyo pull and cannot age. The check that caught it was written on September 8 for exactly this (pulse/tests/test_questions_ledger_email_counts_match.py); it went red on the night of September 12 and that is how this was found rather than by you spotting it. Nothing is broken and nothing failed — every booked email was scheduled by you back on August 2, and they are all healthy. Why you never saw the thin week in the first place: your cockpit measured the runway to its far end, which is four weeks of email and reads as a good month, and an end date cannot show a hole in the middle of itself. Since the morning of September 2 the card prints the count for every week and names any that falls short. What I would do with a yes: write two emails for that week into the repository for you to read and schedule. I never schedule and never send; that does not change. What a no costs: one thin week in a month that is otherwise on target, at a moment when you have better things to do — which is a completely reasonable answer. Evidence: the weekly counts on the cockpit's email card, built from pulse/feeds/runway-cache.json.

Rewritten 2026-09-21 — the email this row named has come and gone without the story. It used to ask about "the Aug 15 email". That email sent on August 15 carrying a different story (the tomato-generosity one), which was the plan all along: the build record says the Well-Being story stays in the concept bank and the built email ships whichever way this is answered (jobs/email/builds/2026-07-30-batch-2-3/build-summary.md, line 35). So nothing was told without Derylin's yes, and the story is still unused (docs/story-bank-v1.md entry 8). The question itself is unchanged; only the date it pointed at had gone. The story bank lists it as the best fit for Christmas, and the holiday section there is thin without it. Originally: Tim would comment on the review board card

Closes a latent gap a reviewer found; nothing is at risk meanwhile

Nothing is at risk either way; the live rules are the ones that run, and a test now reads them directly every time

A yes gives our emails a second well of stories so we stop drawing down your and Derylin's own life. A no is a fine answer and I will record it. The full plan is in docs/email/customer-story-collector-spec-2026-08-06.md

This is one checkbox on the scheduled job, and changing it is a machine setting rather than a repository change, which is why I am asking rather than doing. The report itself now names any missed day on the next report that runs, so the gap is at least visible either way. Evidence: no run recorded on August 7 in .site/pipeline-log.txt, and nothing in the Windows event log between 8:46 PM on the 6th and 5:33 PM on the 7th

The re-fingerprint half of this question already happened without waiting: the Ads workflow rebound the package on 2026-08-20 at 10:26. AGENTS.md and the Rulebook match again, and the file count went from 59 to 116. The design half is unanswered and it bit again the same night. The rebind swept in .gitattributes, the repository's line-ending configuration. On August 21 I had to edit that file to stop 58 sealed customer-catalogue receipts and 8 copies of our own safety gates from being unverifiable in every copy of this repository except this one folder — and editing it turned 37 ads tests red, all of them cascading from that single file. So the package now pins five prose documents plus the configuration that protects it, and any ordinary week's work breaks the binding again. My recommendation is unchanged and now easier to act on: freeze a dated copy of the documents inside the release folder and pin the copies, so the reviewers keep exactly what they read and the living documents stay alive. Nothing shipped and nothing is at risk: the package's own manifest still reads CANDIDATE_PENDING_GUARDED_FIXTURE_VALIDATION, with no production authorization and no package commit, so the reviews it needs are owed either way. The 37 tests are left red rather than adjusted to pass. Evidence: contracts/igl-db/releases/ads-test-records-v1/package-manifest.json (116 members, source_head_at_generation 64a3128); the August 21 commits 6d7ce21 and d4d0cca; pulse/tests/test_governed_ads_package_bytes.py. Updated 2026-08-23: the drift list is two files now, and the second one settles the argument. AGENTS.md — this workspace's operating guide, the one document every agent reads first — was edited at 17:22 on 2026-08-21 by the Ads workflow itself, to record your own written ads-authorization ruling. Thirty-one hours after the same workflow rebound the package to that file's earlier bytes. So the package is now broken by the ordinary act of writing down a decision you made, by the job the package belongs to. Nothing is at risk and nothing is adjusted to pass; it is simply the clearest possible statement of the question. Updated 2026-08-26: the hold has now hidden something. Three of the 37 red tests are not this question at all. One of them - the local ads pilot refusing to write anywhere in this workspace, because G:\iris-03a begins with the legacy workspace's name G:\iris - has been red since 2026-08-17, four days before the freeze broke anything. It sat unread inside a suite that was red for a reason we already had. Fixed on August 26 (bfd3aad); the other two are inside package member files and wait on your answer here. A red suite held open is a place things hide, which is the argument for answering this rather than waiting. Since the morning of August 26 the number is on your morning page rather than only in this ledger. Evidence: docs/ads/governed-package-froze-a-living-file-2026-08-26.md. And the second hidden thing, found an hour later: three of the 34 damaged-receipt cases one of those gates is tested with substitute the literal G:\iris-03a for the receipt's source folder, which is the folder this repository is already in - so they replace the right answer with itself and cannot fail. The gate is fine; three of its 34 proofs have been empty. That one I cannot repair even in principle without your answer, because the file is one the three reviewers actually read, and editing it changes what they signed rather than just breaking a fingerprint. Updated 2026-09-02, a third instance and the plainest one yet. On September 2 I wrote a new operating principle into AGENTS.md — the rule that we never call something unrecorded until we have searched for it by its identifier, earned by a mistake that sat on your morning page for three days. Writing a lesson into the workspace's operating guide is about as ordinary as work gets here, and it deepened the same drift, because AGENTS.md is a frozen package member. No new test went red — the file has been drifted since August 21 and its failure is one of the 36 already counted — but that is the point: the freeze no longer detects anything, it only stays red, and has since August 21. The recommendation has not changed since August 20: freeze a dated copy inside the release folder, pin the copies, and let the living documents live. Updated 2026-09-04 — the cost is bigger than red tests, and I had been describing it too gently. I have been reporting this as "36 of our own checks are red", which sounds like a bookkeeping problem. It is not. The program that performs an attended read of the Meta account checks the frozen package before it does anything else, and it refuses on the same two files: run it now and it stops with governed package member differs: .gitattributes. That check sits at jobs/ads/attended/attended_live_review.py:748, inside the one path both the live read and the practice read go through, ahead of the network and ahead of any credential. So the ads job's own read-and-review program cannot be run at all — not live, not as a rehearsal. The 36 red checks are that refusal happening 36 times, not 36 separate problems. What this does not mean: nothing is at risk, nothing is delivering wrongly, and the ad account is unaffected — the ads keep running and spending exactly as they did. It means that the next time you authorise a read, I would have to tell you I cannot perform it until this question is answered. Thirteen days. Evidence: the refusal reproduced on September 4 against the live repository; pulse/tests/test_ads_attended_live_review.py, whose ten failures are all that same line. Updated 2026-09-09 — a yes buys less than I have been telling you, and here is the missing half. Eighteen days in, I tested the sentence I have been repeating: that all 36 red checks are this one refusal. I made a scratch copy of the workspace, put AGENTS.md and .gitattributes back to the exact bytes the package records, and ran the suite. 34 of the 35 went green. One did not, and it fails for a reason that has nothing to do with the freeze. On 2026-08-20 the ads release package was rebound — 59 sealed files became 116 — and that changed its fingerprint. The last full practice test run against the package was recorded three days earlier, on August 17, and carries the old fingerprint; none has been recorded since. The rehearsal program refuses to start without a test run recorded against the package that exists now, so it has been unable to start since the rebind on August 20, and nobody knew because its refusal was being counted inside this question's 36. What this means for your answer: it does not change it, but it changes what it buys. Answering this question frees the attended read-and-review program, which is the one you would actually use. It does not free the rehearsal — that needs one more thing afterwards, a fresh practice run, which is the ads job's to do once the package verifies again. Nothing is at risk and nothing was touched: not a byte of the package, not a review. The finding is pinned by a test that passes now and goes red the day it stops being true. Evidence: docs/ads/the-rebind-orphaned-every-guarded-receipt-2026-09-09.md; pulse/tests/test_guarded_fixture_receipts_bind_the_package.py.

The read changes nothing and takes seconds. What I found: the figure Klaviyo hands us for each automatic email does not move from day to day. Sixteen of our twenty-one automatic emails reported the same one or two dollar figures across forty days, while the count of people receiving them changed almost every single day — our Welcome Series returned exactly $61.87 on all forty. You cannot cut "the last seven days" out of a number that does not respond to days passing, so the fix we had written down — asking Klaviyo for a shorter period — is not yet known to change anything. One read settles it: ask for the same figures over two different periods and see whether the answers differ. If they do, the repair is real. If they do not, this closes as cannot be done from this source, which is a real answer and a great deal cheaper than a rebuild. Why I am asking rather than doing: the request is technically a "write-shaped" one even though it only asks for statistics and creates nothing — the nightly sync already makes the identical call twice a day — and our own rule for touching Klaviyo from this workspace bans that shape of request in absolute words. Deciding on my own that an absolute rule has an exception is not mine to do unattended. Evidence: docs/email/flow-revenue-is-frozen-not-windowed-2026-08-14.md Updated 2026-09-09 — there is now a measured reason to run it, and it is about the other half of your email income too. Our copy of what each sent campaign earned is written for the last time about two days after the send and then never touched again: 31 of the 40 campaigns since June 1 stopped being updated within three days, 24 of them at exactly two. Meanwhile the store's own record shows a quarter of the orders that arrive carrying a campaign's tag landing after that — including one on the third day after a campaign our copy reports as having earned nothing. I checked whether that proves money is missing, and it does not, which is why this is not a new question: the campaign sent September 4 reads zero in our copy while the store recorded a tagged order the same day, so the store's tag is plainly not the same thing as Klaviyo's decision to credit — the two disagree in both directions across 40 campaigns. Nothing we hold can settle it. The one read you are being asked about here is the only instrument that can, and it would answer this half as well as the automatic-email half it was written for. Evidence: docs/email/the-store-tag-cannot-audit-klaviyo-revenue-2026-09-09.md

The addresses are gone from the live page as of 1:21 AM on August 11, and I checked the live page afterwards rather than trusting the upload. What happened: the folder we publish the website from is the one folder git ignores, so it reads as the private place to put things — and it is the one directory that gets uploaded to a public address every morning. Two sensible decisions that make a hazard when you put them together. The board with the addresses on it was drawn by the older of our two board programs; our own program already writes that board without any addresses on it, which is why taking it down was a matter of publishing what we had. Best estimate of the exposure: about eighteen and a half hours, from 7:00 AM on Monday, August 10 until 1:21 AM on August 11. I cannot tell you whether anyone read it. A separate working folder holding another 17 addresses was one scheduled publish away and never reached the web. Related: this is the same two-folders problem as question 24, which is now the urgent form of it — at 7:00 each morning the other job republishes from its own folder and puts the addresses back. If the answer is bigger than this one board — nobody has ever decided who may read our reports site, and as things stand the answer is anyone with the link — the four choices are laid out one table wide in docs/privacy/who-can-read-our-site-2026-08-11.md, with a recommendation, so that decision is also one word. Evidence: docs/privacy/publish-scan-latest.json, scripts/publish_privacy_guard.py

The capability arrived in the old workspace on August 8 and our safety test caught it as an unreviewed change on the morning of Monday, August 10. I read the whole 127-line difference line by line: nothing was made weaker. Deleting was already on the list of actions that need your per-batch go-ahead, since July 28 — what was added is the part that carries the action out, and it was wired through every existing check rather than around any of them, plus two refusals nothing else has: it will not run without your reviewed "this is not a customer" contract, and it refuses outright on any thread tagged as an open customer ticket. It moves the email to the bin, where it stays recoverable, rather than erasing it. It was used on the night of August 10 at about 8 PM in an attended run: 44 threads, each with its own recorded approval and each checked against Gmail afterwards — so this is a capability you were standing next to, not one that appeared and acted on its own. Nothing scheduled can reach it. I have recorded that review with the new fingerprint, so the test is green and honest; what I have not done is refresh our reference copy, because refreshing it is how a capability stops being visible. Evidence: gates/cs/MANIFEST.json, the two acknowledged_reason entries

Nothing is public and nothing is at risk: the repository is on this machine and its copy on GitHub is private. What is in there: a receipt recording that you personally sent a reply on August 3, naming the customer in the filename and inside the file, along with a one-line description of her missing shirt. It was written before the attended customer-service loop existed and it is the only one of its kind — every receipt written since is counts and states with no person in it at all. What I did instead of touching it on August 15: left it exactly as it is, because deleting or rewriting a receipt to make a test pass is not something we do, and built the check that stops a second one ever appearing — it names this file by hand as the pinned exception, so it stays visible rather than becoming silence. The two answers, plainly: rewriting history means rewriting every commit from August 3 forward and force-pushing, which invalidates any other copy of the repository and is an hour of careful work; leaving it means one name stays in a private history that only you and I read. My recommendation is to leave it, because the exposure is a private repository and the cost of the rewrite is real, but it is your call and I will do either. Evidence: jobs/cs/receipts/20260803-kara-davis-sent.json; pulse/tests/test_no_customer_identity_in_git.py PINNED_HISTORICAL_RECEIPT

Re-checked 2026-09-16 against a better source than this row had, and both halves still hold. The September 13 check read our own copy of the store and our own product-sales table. This one reads Shopify itself: a read-only capture taken 2026-09-15 at 12:04 that pulled all 1,318 products and all 8,136 orders back to 2024-07-21, and whose own verification records zero writes. All three are still on sale — Found It Like This 9368305467607 and 9368305696983 and Lemon Drop Beauty 9368305729751 each come back active, each published on 2026-08-16 and still published on 2026-09-16, a month apart. Not one of the three appears in a single order ever placed. Zero line items across all 8,136. That is a search result and not an empty folder: the same lookup over the same 8,136 orders finds sales for 3 of the other 45 shirts released the same day — Groundhog Tasting, Growing In Harmony and Seedonomics — so the lookup works and the answer is genuinely none. Nothing was taken down and nothing was written to the store. Re-checked 2026-09-13, and two things are worth knowing before you rule. First, all three are still on sale. Our copy of the store, refreshed from Shopify at 23:03 on September 12, gives each of the three products a Shopify status of active: Found It Like This 9368305467607 and 9368305696983, and Lemon Drop Beauty 9368305729751, all created 2026-08-16. Nothing has been taken down, and this shift took nothing down either. Second, and this is the part that makes it cheaper than it sounds: not one of the three has sold a single shirt. Across every day since August 16 our product sales table has no row for any of them. That is a search result rather than an empty folder — 3 of the other 45 shirts released the same day do have sales in the same table by the same identifier, so the lookup works. What that changes: the exposure is a listing anybody can read on your store, not a garment anybody has received, and unpublishing all three costs nothing in sales. Nothing about the artwork findings below has changed. Written 2026-08-20: I have now looked at all three print files myself, which is what this row asked for when it was first written on August 17, and the picture is worse than the hold record said in one place and narrower in another. All three are live and every size and colour of each is buyable right now. 11675 Lemon Drop Beauty is the one I would act on first. It prints a badge reading "Introduced by Seed Savers Exchange 1996" beside a drawing of that organisation's tomato-and-vine mark, a signpost reading "LUBBIN POLAND — Where It All Began", and a portrait titled "Dr. Zalewski's". None of that history is true. The Lemon Drop tomato is an American accident: a sport that appeared among the Snow White Cherry plants of a Florida Seed Savers Exchange member named J.T. Sessions, who saved the seed and offered it through the Exchange, and it won the Exchange's tomato tasting in 2010 — not Poland, not 1996, and no Dr. Zalewski in the record. Three independent published sources agree. So this is two problems, and the second is the expensive one: using another organisation's name and logo is a trademark question, but printing a made-up history in that organisation's name is a false claim about a real nonprofit, on a garment, from a brand whose whole promise is that the seed history is real. There is a better shirt in the true story, and it has the advantage of being checkable. One thing only you can answer: the print file is named 11675_Lauren's Lemond Drop Beauty, and Lauren Zalewski is the Tomato Lovers Collective East Coast leader we were copying on the Carlisle event mail in the week of August 17 — if that portrait is meant to be her, a living partner's likeness is on merchandise for sale and needs her written yes. The two Halloween raccoons, 11509 and 11510, are a smaller and cleaner problem: the word SNICKERS really is legible, twice on 11509 and once plus a partial on 11510, in the brand's own script on its own wrapper. The rest of the candy pile is illegible pseudo-lettering that only suggests brands, and I am not reporting those. There is no false claim to correct on these two — the fix is redrawing the wrappers or dropping the designs. Not second-guessing your approval: you released all 48 on Sunday, August 16, and that stands; what I could not tell on August 17 was whether these three descriptions were in front of you at that moment, and now that I have read the artwork I can at least tell you exactly what is on it. Separately and much smaller: 11509 and 11510 are two different designs published under the identical listing title "Found It Like This T-Shirt", so they compete with each other in search — worth a rename whichever way this goes. Evidence: docs/designs/three-flagged-shirts-looked-at-2026-08-20.md, which names each source and each live link

Rewritten 2026-09-21 — the worry this question was written about was settled on August 26, and nobody told you. It used to say your two August 12 decisions, the $75 monthly spending ceiling and the website-publisher lock, existed on this computer and nowhere else. At 10:10 AM on August 26 the SEO branch that holds both was copied to GitHub (git reflog refs/remotes/origin/seo-roadmap: "update by push", 2026-08-26 10:10), and both records are there now: jobs/seo/decisions/2026-08-12-budget-gate-grant.md and jobs/seo/decisions/2026-08-12-publisher-allowlist-grant.md on origin/seo-roadmap. The ads-process branch the old version counted is on GitHub too. So the question kept asking you for twenty-six days to protect two files that were already protected. What is genuinely only on this disk, counted 2026-09-21 with git rev-list --count <branch> --not --remotes: seo-roadmap, 3 commits from September 9 (the first twenty-eight-day read and the goals sheet); codex/cbo-fair-test-and-cw35-eval-2026-08-31, 4 commits, newest September 2; codex/quarantine-s07-lifecycle-p1-2026-08-30, 1 commit. Nothing on main is at risk — main is copied to GitHub every morning. The same reasoning as before applies: a branch on a private repository is a backup, nobody is notified and nothing merges. The earlier version is kept below, unchanged. Nothing is broken and nothing publishes: this is a copy, not a release. What I found: this repository has three branches of work, and the two that are still being built have never left this machine — the SEO branch, 116 commits and 254 files, and an ads-process branch, 41 commits and 265 files. Between them they hold your two granted decisions from August 12, the seven decision records around them, and the receipts that prove the work behind them. The questions ledger cites two of those files as its evidence, and both rows already tell you they live on a branch — so the ledger is honest; what it cannot survive is this disk failing. On August 18 I pushed main, which was three commits behind and is now level, because that is routine and you authorized it on August 8. I stopped at the two branches because putting 157 unreviewed commits on the shared copy makes them visible in a way that can read as finished, and that is your call rather than mine. My recommendation is yes — a branch on a private repository is a backup, nobody is notified, nothing merges, and it can be removed with one command. Evidence: git rev-list --count main..seo-roadmap reports 116; GitHub lists only main, codex/cro-roadmap-and-cockpit-2026-08-10 and one archive branch

Rewritten 2026-09-21 — the thing this question asked about has been happening since at least August 20, and it was your own instruction doing it. The question asked whether the 6:45 job may copy the morning's saved work to GitHub, unattended. The 7:15 ads digest you set up already does that: the last sentence of its instructions reads "Commit new files to git with a one-line message and push", and a push sends everything saved on main that morning, the 6:45 job's work and the night shift's included. GitHub's copy of main was updated between 7:00 and 7:35 AM on 31 mornings from August 20 to September 20, and on August 29 at 8:46 (git reflog refs/remotes/origin/main; the record on this machine starts August 20, so it may go back further). So a disk failure on any morning since August 20 would have lost at most that one morning, which is what a yes here was meant to buy. Nothing about it is wrong — pushing main is routine and you authorized it on August 8. What is left to decide is only whether it should depend on the digest. If you answer question 51 "stop the digest", the daily copy stops with it, silently. A yes here moves the upload into the 6:45 job, limited to the same fixed list of nine generated files it already saves; a no leaves it where it is, which was working as of September 20. The earlier version is kept below, unchanged. Nothing is broken and the saving half is already running: this is only about the copy off this disk. What was happening until August 19: every morning that job rewrote nine files — your cockpit page, the state-of-play page, both ads scans, the morning report, and the shuffle of reports older than fourteen days into their month folder — and saved none of them. Each one waited for whichever night shift next noticed. August 12's report waited two days, and August 18's was still unsaved eighteen hours later. That is now fixed and the fix is running. What I stopped short of is the upload, because sending commits to the shared copy with nobody watching is a different kind of act from saving them here — it is the same line I stopped at in question 36. My recommendation is yes, limited to the same fixed list of nine generated files and nothing else: it turns a disk failure from a month of lost evidence into a day of it. A no is fine and costs only that the copy stays manual. Evidence: scripts/commit-generated-output.py, the fixed list in its GENERATED_PATHS; pulse/tests/test_commit_generated_output.py proves it never pushes

Nothing broke and nothing was published: our own check caught it before anything was saved, which is the boundary that check exists for. What happened: the new Carlisle event playbook says to copy Lauren Zalewski on every event-shirt reply, and the run wrote her address straight into the playbook, the template and a test. Our repository is copied to GitHub, and no edit reaches a history once it is there — that is question 32, earned once already with a customer's name. What I did on August 20 so the work was not left sitting a second day: the rule stays in the repository — always copy her, and stop the item and ask you if the address is missing — and the address itself now sits in the customer-service job's own local folder that git already ignores. The drafts come out identical. The cost of my choice, stated plainly: that file lives on this computer only, so the playbook would not work from a fresh copy of the repository without it — the same one-disk weakness as question 36. The cost of the other answer: a private person's address in a permanent history, and a precedent for the next one. Our address register holds machine mailboxes, our own addresses and invented test fixtures; not one real outside person. My recommendation is to leave it as it is, because a partner list will only grow and "the rule is in git, the people are not" is a line that holds without me having to judge each new name. A yes to putting them in the repository is a two-line change and I will make it. Evidence: commit c40d0f8; pulse/tests/test_cs_daily_outcomes.py, the two tests added there

Nothing is broken and nothing is at risk; the shirts are for sale and selling. What I found on August 25: Shopify's own product table holds 48 listings created on 2026-08-23 and switched on, under 45 titles, and they are a different 48 from the ones that went live the Sunday before — no title appears in both. What this workspace holds about them is nothing: no activation receipt, no batch folder, no mention in any document, and no sealed batch waiting to be closed out. What that costs you, and it is only one thing: your state-of-play page counts receipts, so it turned the designs job STALE on August 25 on the strength of a receipt from August 16 while your cockpit says a batch landed on the 23rd. Both were telling the truth about different questions and neither said so, which I have fixed — the page now says in words that STALE means unrecorded rather than empty, and points at the cockpit card that reads the store. Why I am asking instead of writing the receipt: a receipt records our own act of publishing, and writing one for an upload I did not watch would make this page start believing things nobody witnessed, which is the one habit that makes every other number here worthless. One thing worth knowing before you answer: the three shirts in question 35 — the two Snickers wrappers and the invented Polish tomato history — are all in the August 16 batch, so nothing on that list touches these new 48, and no artwork review of these 48 is recorded here either. Evidence: dim_products in igl.db, shopify_status = 'active', grouped by creation day — 48 on 2026-08-23 and 48 on 2026-08-16; receipts/designs/ holds one activation receipt and it is the August 16 one; G:\iris\igl-production\.current_batch does not exist. It has now happened a third time. 41 more listings went live on the evening of Monday, August 31 — the store's own record, not an inference — and again nothing in this workspace recorded it. So the store has taken three batches since the middle of August: 48 on the 16th, which has a receipt; 48 on the 23rd, which does not; and 41 on the 1st, which does not. The question is unchanged and it now covers all three: is this you uploading, and may I simply record each batch as yours from the store's own record? A yes ends this question permanently rather than my asking again every time a batch lands. Correction, 2026-09-07: this note said that batch landed on Monday, September 1. It landed on the evening of Monday, August 31 — September 1 was a Tuesday, and the weekday was the tell. The date came from created_at, which is the clock of the program that copies the store into our database, not the store's. All 41 rows carry the identical stamp 2026-09-01 11:03:21, which is that morning's 6 a.m. copy run; the store's own stamps on the same 41 listings run from 7:23 p.m. to 8:43 p.m. on August 31. Your cockpit had it right all along — it reads the store's clock — so two of your pages have been naming different days for the same batch. The same slip moves August 23 and the August 9 and 10 pair as well, and the corrected list from the store's own record is: 24 on Saturday August 1, 27 on Sunday August 2, 6 on Sunday August 9, 40 on Monday August 10, 48 on Sunday August 16, 48 on Sunday August 23, 41 on Monday August 31. Evidence for the new batch: dim_products in igl.db, shopify_status = 'active', 41 rows whose shopify_created_at falls on 2026-08-31; receipts/designs/ still holds only the August 16 activation receipt. Searched by identifier, not by folder, per operating principle 10: two of the August 23 shirts are named in tracked files — a catalogue snapshot taken for the search-demand study and the August 23 scorecard — and neither is a receipt of anyone publishing anything; the four September 1 shirts I checked are named in no tracked file at all

Nothing is at risk while it sits there and nothing new is broken. What it is: at 3:07 PM on Wednesday, August 26, an agent made itself a clean second copy of this workspace to work in, which is an ordinary thing to do. Its work — the 25 vendored agent skills — was finished that evening and folded back in at 8:26 AM on August 27, so the copy is done with. (Corrected 2026-09-21: this used to say the copy was made on the Tuesday. The folder's own creation time says 3:07 PM on August 26, and so does the commit that found it, c1d1a23.) What it cost us: when our checks go looking for things to run they walked into it, found a hundred and twelve pairs of identically-named files, and stopped without running a single check. The 6:45 page on August 27 would have told you a hundred and twelve checks had failed and something in your business had stopped working. Nothing had. That specific hole is already closed — the checks now step around any second copy, wherever it is — and I checked the other three programs that walk the folder on August 28 and none of them can see into it at all. Why I am asking rather than doing it: it sits inside .claude, which your standing rules protect, and it contains a copy of our receipts folder, which I am never to delete. What I checked before asking: its branch has zero commits that are not already in the main record, and it has zero unsaved changes — so there is nothing in it to lose. My recommendation is yes, because a finished copy of the workspace left lying inside the workspace has no upside and has already cost us a day of checks. A no is fine and I will leave it; the checks step around it either way.

Nothing is wrong with the store and no money is missing — only our copy of the record is. What happened: the program that copies each day's takings writes the day once while it is still running, then comes back two days later with the settled figure. It stopped after its 6 a.m. run on the 8th and did not start again until 1:43 p.m. on the 11th, and when it came back it could not reach that day: each run only ever re-reads the three days ending on the day it runs, so the run on the 11th read the 9th to the 11th and every run after it looked further forward still. (Corrected 2026-09-07: this note said 11 a.m., which is that run's time in London. It ran at 6 a.m. here, so the row is holding barely any of that Saturday rather than most of its morning.) Proved on September 7 from the refresh's own records rather than inferred from the row — 275 dated run receipts, read for the first time; across the 60 days to September 6, August 8 is the only day no run ever went back for. What it costs you, corrected 2026-09-13 — the cost moved and the old sentence had stopped being true. It used to be the thirty-day revenue and average-order-value figures on your cockpit, and that ended on September 7, when August 8 dropped out of the thirty-day window; the figures on your page are correct from September 7 onward. What it costs now is August's month-end workbook, which was generated on September 1 into your Opus V folder as IGL-EOM-Report-2026-08.xlsx and reports 313 orders and $16,236.41 of gross sales for the month — about nine orders and $326 short, which is 2.0% of August's sales. Contribution moves less, roughly $200, because the missing orders take their product cost with them. New proof, from files already on this machine and no fresh Shopify call: the live read we took on August 28 for the reward run found two orders placed on August 8, #8846 at $121.63 and #8841 at $61.90 — $183.53 between them, more than the $69.38 our whole day records, and neither one is in our order-date bridge. If you say yes, the August workbook wants regenerating afterwards so the corrected row reaches the file. Evidence: docs/finance/august-8-now-costs-the-month-end-report-not-the-cockpit-2026-09-13.md. Written earlier: the thirty-day revenue and average-order-value figures on your cockpit were short by most of a Saturday from August 8 to September 7, and the page did not say so, because its staleness check only asks how new the newest day is — a day that goes short in the middle of the month looks like a quiet Saturday. That silence was fixed on August 29: the card now names the day and says which totals it touches. What I checked before asking: the neighbouring day, August 7, was caught by the same outage, and it is fine — the live Shopify read we ran for the September rewards ties it out to the cent, along with nine of the other ten days in that window. Across all 758 days we hold, August 8 is the only broken one. What I would run: node scripts/sync-pnl-data.js --run 2026-08-08 2026-08-08 in G:\iris\igl-ops-sage, which re-reads that one day from Shopify and writes that one row. Why I am asking rather than doing it: it writes into the old workspace, which my standing rules make read-only from here, and no exception exists for a small write. My recommendation is yes. A no is fine — the number stays short and the page keeps saying so, which is honest, just less useful. Evidence: docs/finance/one-store-day-was-never-settled-2026-08-29.md

Nothing has published and nothing is at risk: the article is on a working branch, not on the store or the web. Your words on August 12 were "I'd like to review the article with this block in it before we make final approval," and the block has been in the article's body since the rewrite the next day, as the section "The one that was never a plant". Your approval covered that one article and nothing else, so this is not a standing release either way. Why you are only seeing this now, and it is my fault rather than a new problem: this ask has been sitting in the night shift's own work ledger since August 13 with your name on it and a due date of August 21, and that ledger is not a page you read. It is here now, and a check added on August 31 stops any future item of yours living only in there. Evidence: docs/story-bank-v1.md entry 23; docs/night-shift/BACKLOG.md NS-034

Nothing is built and nothing is blocked by this: no email has sent yet, so there is no candidate waiting. The reason to answer it now is that the rules do not depend on which story goes first, so having them settled turns the first conversion into half an hour of work rather than a design argument. The one rule the rest follows from is that an email is a letter to people who already know us and an article is a page for people who do not. Why you are only seeing this now: same reason as question 43 — it has been in the night shift's own work ledger since August 13, due August 21, with your name on it, and that ledger is not a page you read. Evidence: docs/email/email-to-blog-conversion-spec-2026-08-13.md; docs/night-shift/BACKLOG.md NS-011

Nothing in them is wrong except the word. Every figure — sales, product cost, Meta ad spend, card fees — is correct and unchanged; only the name on the total was wrong, and it was wrong in your favour. How much: your reconciled 2025 books put that year at -$53,480.94, and the same 365 days read the way that workbook reads a month come to +$17,133.09. The $70,614 between them is contract labor, subscriptions and interest, non-Meta advertising, merchant fees beyond what our daily table captures, and product cost above the Printify invoices — none of which lives in any table that job can read. Two things you should know either way. First, that job could not run at all between August 28 and September 1: a repair I made to it four nights ago broke the file, nothing imports it so no test noticed, and its next run was due September 1 for August. It is fixed and I re-ran July against it to prove no figure moved — July came out at -$2,710.76 before and after, to the penny. Second, August's workbook is yours to generate and send whenever you want it: python jobs/finance/eom_report.py --year 2026 --month 8. Why I am asking rather than just reissuing: Darla may already have entered those five, and five replacement files landing unasked in her folder is her problem to sort out, not mine to create. Evidence: jobs/finance/eom-report-spec.md, docs/wayfinder/books-vs-database-2025.md, receipts/finance/202607-eom-report.json

Rewritten 2026-09-20, and this is the second rewrite in two nights for the same reason. The row's previous ask was answered by action eight hours after it was written. The rewrite of 2026-09-19 said "no run since has written a receipt". That was true at 1 AM on September 19. At 9:38 AM the same morning an attended run finished and wrote one. What that run did: it started from 80 threads in the Inbox — the largest any recorded run has faced — filed 30 away, binned 35, and left 15. It wrote 1 reply, left alone 3 drafts already there, and left 13 threads needing your own action and 2 decisions. send_capability_used: false: nothing was sent, which is permanent. Why nobody knew: the receipt was never committed and sat on this machine only for about fifteen hours. The morning checks of 2026-09-20 found it — the stranded-evidence audit named the unsaved receipt and the question-premise check, written the night before for exactly this, named this row against it on its first night of real use. Both are now saved. What changed on your pages: the state-of-play page turned customer service from STALE back to CURRENT, 15 completed runs, most recently 2026-09-19. The STALE reading of 2026-09-19 was true of the evidence and false of the world. What is not claimed: whether any of those four drafts have since been sent or those 13 threads worked. Checking means opening the live mailbox, and customer service is attended by your ruling of 2026-08-12 precisely so no unattended process touches a customer thread. Nor that the three preserved drafts are the same three each time — September 3, 10 and 19 each record exactly three, and a repeated count is not an identity. What it costs you: the last full run took about forty minutes; sending four written replies takes minutes. Evidence: docs/cs/question-49-was-overtaken-again-eight-hours-after-it-was-rewritten-2026-09-20.md; jobs/cs/receipts/20260919-093846/morning.json

Rewritten 2026-09-16 — the ask named a deadline that has gone by. It used to end "before your surgery", which was the reason to hurry when it was written and is now a date in the past sitting inside a live question. The change to make is the same one and the reason it is worth making is unchanged: any stretch where this computer is off for three days still loses those figures for good, surgery or no surgery. Only the urgency clause is gone. Why now: with your surgery in the first week of September this computer may sit switched off for several days, which is exactly the condition that did this in August. I do not hold the date of the operation itself, only the week, which is why this says the week rather than a day. What it is: the twice-daily refresh runs with no arguments, so it takes its built-in default of three days. The wider window is an option the program already has and already documents — --days 7 — added to the one line in G:\iris\igl-ops-sage\scripts\daily-rebuild.cmd that launches it. Nothing else changes; it simply re-reads a week instead of three days, twice a day. What it costs: the run takes about three and a half minutes and would take roughly twice that. Nothing you wait for depends on it finishing. What it does not fix, said plainly: a stretch longer than a week still loses days, and this does not repair August 8 — that is question 41, a separate one-day command. Why I am asking rather than doing it: the line lives in the old workspace, which my standing rules make read-only from here. My recommendation is yes, and I would do it before you go in rather than after. What I checked before asking: the catch-up setting in question 22 would not have saved August 8 — a caught-up run still computes its window from the day it actually runs, so a run on the 11th reads the 9th to the 11th whether it was caught up or on time. Evidence: the two scheduled jobs IGL-Rebuild-Morning and IGL-Rebuild-Evening, both launching daily-rebuild.cmd with no arguments, and daily-sync.js line 90, where the three-day default is written. Corrected 2026-09-08 — this question was smaller than the thing it describes. The three-day look-back is not a setting on the store copier. It is one value on one line, handed to every source the refresh runs: Meta ads, the store's takings, product sales, Printify orders, Klaviyo campaigns and flows, and both GA4 feeds. So an outage does not only cost a day of takings — it can cost that day in any of them, and the same one word repairs all of them at once. What I checked before widening it, because the wider version sounds more alarming than it is: our copy of each day of the ad account is written for the last time two days after the day and never revisited, while Meta keeps crediting purchases to an ad for seven days — so it looked as though every kill and scale verdict was being taken on a number two days short. It is not. Meta's own live read of the account re-counts the same days at full maturity, and across fifteen comparisons out to twenty-seven days its figures match our frozen copy to the cent on revenue, purchases and spend. That check now runs every morning and puts a line on your page only if it ever stops being true. So this question is about outages and nothing else, which is the version I would answer yes to. Evidence: docs/finance/the-three-day-window-covers-every-source-2026-09-08.md; pulse/tests/test_attribution_settling.py. Added 2026-09-21 — that last sentence holds for Meta and has never been shown for email. The full-maturity comparison was possible only because Meta will re-count old days for us. Our copy of each email campaign's sales is also read for the last time two days after it sends (the sync log in our database shows each campaign re-read on its first and second day and never again), and nothing we hold can say whether Klaviyo credits more to it afterwards; that is the read question 31 asks for (docs/email/the-store-tag-cannot-audit-klaviyo-revenue-2026-09-09.md). It is worth knowing because five of the six campaigns sent September 4 to 18 show $0 in our copy — $160.60 across all six, against $1,489.14 from the sixteen sent in August. If Klaviyo does credit sales after day two, a week-long look-back would pick them up too; if it does not, those zeros are real.

Nothing is broken and nobody has missed anything yet — the emails exist and they are good. They are oct02-the-drawing-table (the holiday peek), oct04-the-gardeners-saint (the Sunday St. Francis letter) and oct06-october-releases (the October roundup). All three were built on the night of July 30 and cleared fact-check then. Why they never went: two of them name products, and on July 30 you set the rule for exactly that — build catalog-dependent emails with the batch, then refresh them against the live store and push in the last one or two weeks of September. That rule was right. The refresh window opened at the start of September and no one was watching the clock, because nothing on your cockpit could see an email that had been written but never pushed. That blind spot was fixed on the night of September 16 and the card now names all three. The third one, oct04-the-gardeners-saint, carries no hold at all — it is finished, cleared, and simply never left the build. What it has already cost, which is the reason I am asking rather than filing it: three built emails had send dates of September 2, September 8 and September 12, and Klaviyo shows no campaign sent on any of those three days. Your list went eleven days in early September on four sends. Why I am asking rather than doing it: creating a draft in Klaviyo is a write, and campaign creation is frozen until you lift it for a named batch in a live sitting. I never schedule and never send; that does not change. What a yes costs you: about twenty minutes to read three emails you have already approved once, in a sitting where you lift the freeze and I push. What a no costs: the first week of October is empty, and these three were written for it. Evidence: jobs/email/builds/2026-07-30-batch-2-3/slot-status.md rows 29, 30 and 31; the two push receipts in receipts/email/, which between them name 27 campaigns and none of these; pulse/feeds/runway-cache.json for the September send sequence (Aug 31, Sep 4, Sep 6, Sep 10, Sep 14); pulse/tests/test_cockpit_emails_written_but_never_pushed.py.

Added 2026-09-17, because the question was being asked somewhere this ledger forbids. Every question for you is meant to live here, and this one has lived only in the last paragraph of the 7:15 page since August 27, three weeks of mornings. The evidence for yes is your own use of it: the six advertisements it named as confirmed kills between September 11 and 13 were all switched off by you in Ads Manager by 9:10 PM on September 16 (question 47, closed). A yes means one edit to the digest's instructions, which live in your Claude settings folder and so need your word: remove the trial paragraph, and — the same edit — have it read Meta's change log each morning, so a line like the September 16 one, I can see that it came back on, but not who did it, names the person and the minute instead. That read now exists and was proved on September 17 (jobs/ads/change-log/read-account-change-log.mjs). A no stops the 7:15 page; the cockpit's ads card and the Monday board carry on. Nothing is sent, changed or switched on either way.

Found on the night of September 22 by looking, not guessed at. The folder is C:/Users/Tim Dobyns/.codex/worktrees/4a9b/iris-03a, a working copy Codex opened on September 12. It holds 120 files that were never saved into our repository and are not on GitHub: the rule itself (two documents in that folder's own copy of docs/agents, named independent-review and review-methodology, both dated September 12, with a record saying Claude and Grok each reviewed it and it was "adopted for this workspace"), an edit to AGENTS.md putting it in force, and six review pages written September 12 to 15, among them an Iris consolidation proposal and a business view. Why it matters now: the October–November email plan written on September 21 was reviewed under neither rule — its own record says it used a GPT model because the Opus reviewer the August 12 rule names was unavailable. Agents can only follow the rule they can read. What I have not done: saved anything, because nothing here proves the rule is really yours, and the one line in AGENTS.md also waits on question 30, which freezes that file. A scan of the 120 files found no email addresses. What a yes costs you: nothing further — I save the rule and the review pages as they stand, and point AGENTS.md at them once question 30 allows. What a no costs: nothing breaks; the August 12 rule stays in force and I record that the September 12 draft was not adopted. Evidence: python scripts/stranded_evidence_audit.py --other-worktrees, and git status inside that folder.