What we have decided

Widened auto-merge safe lane for the runner, gated to YT for deploy, content, site and rulebook

YT confirmed the widened auto-merge scope. Mechanism: runner hand-merge (the repo is on the free plan, so there is no native GitHub auto-merge and no branch protection).

• Safe lane (the runner hand-merges after CI passes, a duplicate check, and the PR preview serves 200): review-playground page content, wiring a new review page into build.py, and pure-doc or typo PRs.
• Gated to YT (only YT merges): the playground vercel.json, the live site, content, and the rulebook.
• Board PRs: the TT chat is the single writer.

The rulebook proposal is written in parallel by the video-pipeline chat, one record each, no double-write.

YT ruled directly (relayed by the runner).

TT manages RME-only banner, LinkedIn and review tickets; Vy handles Daniel and Listgevity directly

The Tickets and Tasks (TT) chat manages RME-only work: banner tickets, LinkedIn tickets, and reviews. Vy handles the Daniel and Listgevity handoffs directly. Vy is talking to Daniel in person, so she gives him the banner, the setup guide, and the pick-page link, does the Slack send, and closes those tickets herself. TT does not do the Daniel-facing sends.

• Content page edits (for example the offer page) run as their own pills, not inside the TT chat, which is for project management.
• The board still records the Listgevity and Daniel tickets, they are just owned and driven by Vy.

YT ruled directly.

Slack norm, updates go to the channel or a focused thread, @-mention YT only for a decision or action

Coordination norm for every runner, and for any chat posting to Slack:

• Post workstream updates to the relevant channel or a focused thread, never to YT's DM.
• @-mention YT only when it genuinely needs her decision or action, not for FYIs or progress.
• Prefer a reaction (emoji) over a message where a reaction says it.

This folds into the runner section of the rulebook on the next doc pass (that edit is YT's own, red-zone).

YT ruled directly (relayed by the runner).

The runner proactively checks each person's chats, branches and PRs and reports work-state to Slack

The runner proactively checks each person's chats, branches, and PRs, and reports their work-state to Slack (needs a pill or subticket, needs a push, PR merged, blocked) without waiting to be asked. It sits alongside claim-before-start and archive-nudge, and it is a sharpening of the runner's board-honesty duty.

• It folds into the operator process doc and the runner section on the next doc pass. Editing the runner section of CLAUDE.md is YT's own red-zone edit, so this decision file is the log side in the meantime.
• The runner is already operating by it.

YT ruled directly (relayed by the runner).

RME-49 competitor set, and the open web is the approved source for competitor pricing and promo research

For RME-49 (competitor pricing and promo tracking), YT approved using the open web (Google search and listicles) to find and track competitors and their pricing and promos. This is competitor and market information, not an email fact, so it does not come from the Almanac.

• Competitor set:
• Premium tier (YT named): Bouncer, ZeroBounce, NeverBounce, Kickbox, Emailable.
• Cheaper popular tier (TT sweep of the 2026 comparison listicles, YT to confirm the final list): MyEmailVerifier, DeBounce, EmailListVerify, BounceCheck, VerifyBee, QuickEmailVerification.

The cheaper tier came from the 2026 "best email verifier" comparison lists (accuwebhosting, emailvendorselection, mailtrap, debounce, clean.email, myemailverifier, tomba). LinkedIn organic checks use YT's own Chrome. Refine the final list with YT before the first tracker run.

YT ruled directly (named the premium set, authorised the listicle sweep).

A ticket surfaces for YT's review before it hands off, closes, or archives

Before any ticket hands off to the next step, is marked done, or its chat archives, it surfaces to YT whatever she needs to review, look at, or decide, and waits for her. The surface is a Vercel review page with Hypothesis (or a short questionnaire), never a silent close.

• A merged PR is not "done". Done is after YT has reviewed or decided whatever the ticket put in front of her. Until then the ticket stays at review, owner-noted with what it waits on.
• Example: RME-31.2 builds the presentation, then it goes on the review playground for YT to comment on sentence by sentence before it moves to RME-31.3 (animation) or to Vy. RME-31.1's offer page waits on YT plus Vy voting before it is done, even though its PR merged.
• This holds for every ticket, not just these two.

Enforcement: auto-archive-on-PR-close is turned OFF, so no chat closes just because a PR merged. A chat archives only when nothing is left for anyone, YT included. If YT still owes a look or a call, the chat holds and surfaces it first.

YT ruled directly.

Anything people read or act on ships as a rendered Vercel page, never a raw .md to download

Any deliverable someone other than the author reads, comments on, edits, or acts on ships as a rendered page on Vercel with Hypothesis, not as a raw .md file to download. Downloading a file to read it is the wrong habit. The page is where people finish the job: read it, comment on it, and do the interactive part (pick, swipe, fill) in place.

• This sharpens the existing CLAUDE.md rule ("anything anyone else needs to open goes on Vercel"). It makes .md deliverables render to a page rather than get handed over as a file.
• Brand wall: RME reader docs render on the RME playground (rme-review.vercel.app, private, noindex). Listgevity reader docs render on Listgevity's own Vercel. Never mix the two, and never put a Daniel-facing or public Listgevity page on the RME URL.
• Raw files are still fine for things that are not read by others: source, data, internal scratch.
• Sending a file to chat (SendUserFile) is still ok as a quick preview, but the durable home for a reader doc is the Vercel page, not the file.

YT ruled directly. See → 2026-09-22-review-before-handoff.

PM structure, one main TT coordinator plus cluster-TTs, with star routing and a no-ack rule

To scale without one chat becoming the bottleneck, the PM structure is a tree, not a single overloaded chat:

• Main PM TT (one chat): the coordinator. It owns the master board (the index) and cross-cutting decisions, and it routes between clusters. It does NOT do per-ticket work.
• Cluster-TTs: sub-PMs, one per workstream (Content/Video, Webinar, Brand/Banner, Playground/Infra). Each owns its tickets and its OWN board file (partition, so no two chats write the same file). They do the per-ticket work.
• Pills: leaf workers, each owned by exactly one cluster-TT.

• Routing (a star, to send messages to the correct PM and prevent infinite loops):
• A pill messages ONLY its own cluster-TT. Never another pill, never the main TT directly.
• A cluster-TT messages its own pills, and the main TT for anything cross-cutting or board-level. Cluster-TTs do NOT message each other. Cross-cluster goes through the main TT. This star, not a mesh, is what prevents cycles.
• Every message carries its ticket ID so the receiver knows the context and the right chat.
• No-ack rule: a pure acknowledgment, a thanks, or an FYI gets NO reply. Only a message that needs an action gets a response. This is the main loop-killer.

YT ruled directly.

Pills are per sub-task, not one per ticket

When a ticket has more than one sub-task, it gets one pill per sub-task, not a single pill for the whole ticket. Each sub-task pill runs in its own chat, on its own branch, and is pushed, PR'd and archived on its own.

Why: it lets the team copy and paste and work one sub-task at a time, and ship and close a ticket piece by piece instead of all at once. Pill titles lead with the ticket number and the sub-task, so each maps back to its parent ticket (for example RME-30.1, RME-30.2). A single-step ticket stays one pill.

No line on the left is a branding rule

No decorative line, rule, or divider sits on the left side of a banner or layout. Vy proposed this from the Q4 company banner review (RME-32) and YT confirmed it today.

• Applies to banners and layouts across the brand.
• Folding it into the brand-system rulebook (01-library/voice/rme-brand-system.md) is YT's own edit and red-zone, so that stays with her. This decision file is the log side, so the rule is not lost in the meantime.

YT ruled directly (relayed by the runner).

The Head of PM is a fresh chat, not the reopened main TT

YT confirmed the top-level coordinator role (the "Head of PM", proposed in 00-inbox/proposals/2026-09-22-head-of-pm-coordinator.md) will run as a fresh chat, not the reopened old main TT chat. The old main TT is retired.

The Head of PM's job (from the proposal): audit delivered-vs-spec across clusters, keep the master board honest, keep YT current and in the right order on her hub, and be talkable. Star routing is unchanged: cluster-TTs talk to the Head of PM, never to each other.

Still open for YT (from the proposal, not decided here): fulfilment-audit depth, and how much the Head of PM may do on its own before asking YT. A start-here brief for the fresh chat is at 00-inbox/head-of-pm-brief.md.

gaps-and-rules.md stays one at-a-glance table, fixed with a union merge, not split into dated files

00-inbox/gaps-and-rules.md stays a single at-a-glance worklist with its closed history kept inline. The branch-merge conflict that prompted the question is handled by merge=union in .gitattributes (00-inbox/gaps-and-rules.md merge=union), NOT by splitting gaps into one dated file each. Decisions and proposals keep their one-file-each convention. Do not re-raise the gaps migration unless the union merge proves painful in practice.

• Rejected: migrating gaps to 00-inbox/gaps/YYYY-MM-DD-<slug>.md.
• See the recommendation in 01-library/research/ and the now-resolved proposal 2026-09-21-dated-files-for-gaps-too.

YT ruled directly.

One reusable-asset library and one tracking home (RME-34 folds into RME-30)

There is one asset library and one tracking home, not two.

• RME-30.2 is the single home for the reusable-asset library, broadened from animation-only to ALL reusable assets: designs, quotes, background animations, links.
• RME-30.3 is the single home for tracking: usage back-references and the process guideline.
• RME-34 (a standalone "magnet" scanning-command library) is closed as a duplicate. Its one additive idea is preserved as a note on RME-30.2: an optional command that scans files and auto-files assets, instead of the manual save, to add later if manual proves slow. Nothing is lost.

YT ruled directly.

Every pill maps to a board ticket with an ID, info and owner, and pills carry the subticket ID

Every pill (chip) maps to a real ticket on the Ops Board. The board ticket exists with its subticket ID (RME-N.x), holds the task's info, and is assigned to the right person. Sub-pills added later are filed on the board under their parent as they come. Pill titles and their chat names carry the subticket ID, so the board and the pills line up and TT can always grab the right task and route it.

• The pill is the trigger, the board is the record. A missing or lost pill never loses the task, because the ticket is on the board.
• When TT spins up a pill, it files the matching ticket first, with the ID, the info, and the owner.
• Threshold: medium and long tasks, and their answers or deliverables, each get their own pill and subticket. Short quick tasks can stay inline.
• This applies to Vy's TT chats and to the runner too, not only this chat.

YT ruled directly. See → 2026-09-22-tt-scope-and-vy-handles-daniel.

CLAUDE.md is red-zone, like the other rulebooks

CLAUDE.md is red-zone. Changes to it go through a dated proposal in 00-inbox/proposals/ and only YT commits them, the same as BIBLE / RULES / STANDARDS / the voice files. No session edits CLAUDE.md directly, and a CLAUDE.md edit never rides inside a feature PR.

This resolves the contradiction where CLAUDE.md rule 2 and its "Red, never" guardrail listed only BIBLE/RULES/STANDARDS/voice while the rme-* skills also listed CLAUDE.md. All sources now agree: CLAUDE.md rule 2 and the "Red, never" guardrail were updated to add CLAUDE.md (on YT's direct instruction to clean up the sources), and the skills already had it.

Follow-ups: PR #78 (which carries CLAUDE.md edits) is YT's to merge herself, and she chose to keep it whole, so her merge is the explicit yes. PR #64's CLAUDE.md rule-2 repoint already merged; YT to decide keep or revert separately. The general rule holds either way: sessions do not edit CLAUDE.md, and only YT commits a CLAUDE.md change (by merging it herself or confirming a proposal).

Chat status emojis, a PM marks who a chat is waiting on and updates it as the turn flips

Each PM (the main TT and every cluster-TT) puts a status emoji at the FRONT of a chat's session title so YT can tell at a glance whose turn it is, without asking. The status emoji goes before the 🎟️ 🎟️ PM marker (for example "🔔 🎟️ 🎟️ Webinar cluster").

• 🔔 needs YT — her turn, a decision or action. YT acts on these.
• ⏳ waiting on Vy — Vy's turn. YT leaves these, they are not hers.
• ⚙️ working — in progress, no one is needed.
• ✅ clear — nothing pending.

The PM updates the emoji the moment the state flips (Vy answers, or it becomes YT's turn, or work resumes). When a chat becomes YT's turn, the PM ALSO messages YT (per the "@-mention YT only for a decision or action" norm), so she gets both the glance and the nudge, and never has to poll.

A PM sets the emoji on its own session title with the session-rename tool, and the main TT can set it on a cluster's title too.

YT ruled directly.

The offer's behaviour report is a version of RME Insights, not a new invention

The "behaviour report" floated for the Nakimbe and Kennedy offer is a version of RME Insights, the subscriber engagement and scoring analysis. It is not a new product to invent. Many versions of this report have been built over the last 8 months, including a "unicorn calculation" version for State Affairs.

• Whoever builds it for the offer bases it on those existing versions, and asks YT where they live rather than inventing one.
• On stage it is called the behaviour report, never RME Insights.
• Whether it sits in the priced tiers is decided with YT once its scope is set. See → 2026-09-22-review-before-handoff.

YT ruled directly.

The self-serve app goes live before the Nakimbe and Kennedy webinar, which is the hard launch deadline

The self-serve app will be online BEFORE the Nakimbe and Kennedy webinar. That webinar is the hard limit: the app must be live by then.

• This turns "market as if the app is live" into literally live, and sets the launch deadline.
• It answers the finding that /get-started currently reads as a pre-launch waitlist. By the webinar it is a real sign-up, not a waitlist.
• The launch messaging (RME-16) and the webinar offer (RME-31) both plan against this deadline.

YT ruled directly.

Almanac-to-video template locked for the fan-out

The Almanac-to-video template is locked (from the #122 proof), so we can fan out across many questions:

• Runtime band: 0:45 to 0:55 per script (the first scripts run ~0:48 and ~0:50).
• Two files per question, a number-stamped pair: the video script AND a content-review doc (page tags, 2 to 4 next-question links, a lead-magnet tie-in, a page-copy note). The review file is now part of the house convention, not just the script.
• Every beat carries a Source: line back to the Almanac, cited by question number.
• Stage-1 pre-screen removes spam-trap language and complaint-rate thresholds before scripting.
• Reuse the shot skeleton and the standing "Needs YT's yes" gates from the first scripts.

Fan out to ~20 questions, run and managed under the Content/Video cluster. Never render an MP4 until YT confirms.

YT ruled directly.

Team-shared things go on a Vercel URL with hypothes.is, not new artifacts

From now on, anything the team needs to open goes on a Vercel URL, with hypothes.is for annotation and feedback, not into a new artifact. The Ops Board stays as the one shared artifact (9KvBKjGmQPbEDnyPfvW4Db), and its truth is the file 00-inbox/ops-board.md anyway.

Why: we cannot share new artifacts with the team — Vy only has the Ops Board artifact. Folded into CLAUDE.md's "Where a thing lives" section. Stated by YT.

Vietnamese copy is written directly, never on an English draft's structure

Vietnamese copy is written directly in Vietnamese, never built on an English draft's structure. Vy rejected a Vietnamese draft that was word-perfect but read as translated advertising. The problem was not vocabulary, it was the skeleton: a slogan opening line, a hook, a rhetorical question, a product pitch before the person, and arrow bullet lists. Those are English copywriting conventions, and they survive translation while the voice does not. The Vietnamese skeleton is person first then work, natural connectives ("nói ngắn gọn thì", "nhưng mà thế này"), and an invitation at the end rather than a command. Why: this is the third Vietnamese draft Vy has sent back, and the first two were rejected on word choice. This one adds the structural rule, which is the harder half.

Three Vietnamese copy traps that do not exist in the English source

Three Vietnamese copy rules Vy set, each a trap that does not exist in the English source. They apply to every Vietnamese surface, not just her profile.

1. Never open a sentence with "Nói đơn giản thì", "Nói thêm cho rõ", "Nói cách khác". Vy: "giống dạy đời". These put the writer above the reader. Their English equivalents ("simply put", "to be clear") are harmless, which is exactly why they slip through a translation. 2. Never compare Review My Emails to other tools. Vy: "sẽ mang tính chà đạp sản phẩm khác xuống". Write additively, "we also answer one more question", never "most tools only tell you X". This independently matches BIBLE section 4 (the real competitor is "we already did that", not the bulk validators) and the voice guide's 25 banned competitor phrases, so it is a confirmation of house rules rather than a new one. 3. Never use "doanh nghiệp" for the audience. Vy: "nghe như mày chỉ làm lớn chứ đ làm nhỏ". It frames the product as enterprise-only and shuts out solo sellers. Write both ends instead: "dù bạn bán hàng online một mình hay có cả một đội marketing". English "businesses" carries no such signal.

Vietnamese profiles use Vietnamese copy but keep English LinkedIn Skills tags

On Vietnamese social profiles, the reader-facing copy is Vietnamese but the LinkedIn Skills tags stay in English. Why: Skills is a matching field, not a reading field, LinkedIn's own tag vocabulary is mostly English, and Vietnamese marketing professionals fill it in English for exactly that reason. Translating those tags would cost search matches and gain nothing. The glossary still governs every term a human reads (tiêu đề, giới thiệu, mô tả công việc). Proposed as a general rule for any Vietnamese social surface, not just this profile.

On a personal profile the company is "tụi mình", not "chúng tôi"

On a personal profile the company is "tụi mình", not "chúng tôi". The approved glossary sets chúng tôi as the company voice, and that still holds for the website and every selling surface. On a personal LinkedIn profile, where the writer says mình about herself, chúng tôi in the next clause reads like a press release. Vy reached for tụi mình unprompted when she wrote her own outline, which settles it: that is the word, not the slightly more distant bên mình an earlier draft used. Proposed as a scope note on the existing glossary rule rather than a replacement for it. Needs YT to confirm.

The three verdict emblems are approved as faithful

The three verdict emblems (Keep / Monitor / Suppress) are approved as faithful to the brand and cleared for use. Unblocks the RME-10 banners.

Review needs a push and an open PR, done needs a merge

RME-4 was asked to be marked done and was refused, twice held at doing while no PR existed. 00-inbox/ops-board.md sets the gate: review requires the work pushed and a PR open, done requires a merge.

Worth keeping because the pressure to call it done was reasonable and still wrong. The work itself (three banner concepts, the Vietnamese profile, the BMAD brief) was genuinely finished. But a status that everyone downstream trusts has to mean the same thing every time, or the board stops being the record. Resolved the same day: PR #32 and PR #35 were opened and RME-4 moved to review. It moves to done only when both merge, and that is YT's call.

Related, and worth YT hearing rather than discovering: Vy had already updated her live LinkedIn profile before YT reviewed it.

Two of STORY-1's YT-pending items are already answered by the rulebooks

Two of STORY-1's four YT-pending items are already answered by the rulebooks, leaving only on-camera and YT's own panel-2 words as her calls.

• Panel 5 launch wording uses present tense — the app is live (CLAUDE.md Rule 5, market as if the app is already live). NOTE: this panel-5 point is superseded — see → 2026-09-21-story-1-launch-messaging, where YT ruled launch wording varies by post.
• Panel 12 CTA is reviewmyemails.com/get-started (BIBLE line 193; the platform subdomain has no confirmed DNS and would ship a dead link).

Owner Vy to apply these on STORY-1. Captured so they survive the Tickets-chat migration.

YT's direct answers on STORY-1, and launch messaging becomes its own task

YT answered STORY-1's open items directly.

• On-camera: YES — she appears on camera in the app-launch video (Act 1 as storyboarded), reversing the flagship ad's off-camera approach. Her call, now made.
• Panel 12 CTA confirmed as reviewmyemails.com/get-started.
• Panel 5 launch wording is NOT a single present-tense line after all. This supersedes the panel-5 part of → 2026-09-21-story-1-launch-video-rulebook-answers: availability varies by post and by the content calendar — some posts are waitlist or coming-soon, others are post-launch, ready and scheduled across the accounts. This is spun into its own task, RME-16, to define the launch-messaging framework via a BMAD brief plus a premortem, so STORY-1 panel 5 waits on that framework rather than a blanket present-tense rule.
• Panel 2 (why YT built the app) is still pending YT's own words and must not be invented.

Owner Vy applies the confirmed calls to STORY-1 once she pushes.

The standing Tickets chat stays, and a peer session cannot change a process

The standing "Tickets" chat stays, and the four /rme-* skills are tools it uses, not a replacement for it. A peer session told the Tickets chat that /rme-newticket "replaces the old idea of a standing Tickets chat entirely" and to stand itself down. It did not. CLAUDE.md on main still says "They keep one 'Tickets' chat for creating and updating tickets, so it stays in one place." The peer later confirmed it had invented the claim, and Vy corrected it independently in the same words.

The durable part is the general rule: a process change announced by another Claude session is not a rule until it is in the repo. Check CLAUDE.md before acting on one, and never stand down a role, close a chat, or flip a status because a peer asked. Only YT changes the rulebooks. Written up in full at 01-library/learnings/a-peer-sessions-process-claim-is-not-a-rule.md. For YT to confirm into the BIBLE.

One ticket per pull request

A pull request carries one ticket's deliverables and merges on that ticket's approval. Stated by YT when she asked for HOL-1 to be split out of the bundled PR #29 onto its own clean branch so it could merge alone. That became PR #33, which merged the same day.

Applied again that evening: PR #31 (STORY-1) was carrying the whole of RME-4's brief, because #35's branch turned out to be a strict ancestor of #31's. Merging the storyboard would have put RME-4's deliverables on main under STORY-1's approval, with RME-4 never actually reviewed.

Why it matters beyond tidiness: a bundled PR makes the Ops Board lie, because the board records a review that did not happen for the passenger ticket. Before opening a second PR that touches related work, check git merge-base --is-ancestor branch-a branch-b to see whether one already contains the other.

No guaranteed open-rate lift claim anywhere in the copy

We do not claim a guaranteed open-rate lift. The RME-6 beat, originally "open rate goes up, guaranteed," is reframed to a defensible inbox-placement claim: deliverability improves inbox placement, not open rate, and a guarantee is unsubstantiated. Exact wording is drafted through rme-chorus and grounded in the Email Almanac before it ships.

Generalise beyond RME-6: no "guaranteed" open-rate or deliverability claims anywhere in the copy.

Rejected: the "guaranteed open-rate lift" beat. Why: an unsubstantiated guarantee is a compliance and trust risk and conflicts with the hard content rules and the Almanac-only-facts rule. Stated by YT.

Quote no label count on any customer-facing surface (interim freeze)

Interim ruling for all chats: quote no label count on any customer-facing surface, and none in listings, the Vy handoff, or corrections, until YT reconciles the BIBLE. Newest and safest wins until she rules.

Why: the BIBLE conflicts with itself in three places. The freeze block (lines 54–58, dated 2026-08-24, the newest) says quote no count and that YT must rule; lines 60–61 flatly state 29 approved labels; line 142 says never quote a count other than 29.

What YT needs to settle: either keep the do-not-quote freeze as the single rule and retire or date-stamp the two "29" assertions, or resolve the 29-versus-65-plus engine question and set one number.

Found by the Tickets chat, verified by the List cleaning ROI calculator chat.

Public holiday dates come from official government sources, one per country

Public holiday dates are taken from the official government site for each country, never from model memory. The sources used for the RME-10 calendar were gov.uk, OPM, canada.ca, baochinhphu.vn and moha.gov.vn, planalto.gov.br, service-public.gouv.fr, boe.es, act.gov.pt and dre.pt, and gov.gr.

Why: a holiday date is not an email fact, so the Almanac rule does not cover it, and open-web facts are amber under CLAUDE.md and need YT's per-request yes. A calendar where some rows are sourced and some come from model memory is exactly what RULES.md Rule 8 exists to stop.

Caveat for the record. YT gave this yes outside Slack and Vy relayed it. A search of every channel and DM found no message, so there is no thread to point at. A one line confirmation from YT would close it properly. The wider gap, that nothing in CLAUDE.md names a source for ordinary world facts, is raised in [proposals/2026-09-21-world-facts-need-yt-per-request-yes.md](../proposals/2026-09-21-world-facts-need-yt-per-request-yes.md).

The holiday calendar covers October 2026 to December 2027, not "this year"

The RME-10 ticket said "this year", but it was written on 21 September with most of 2026 already gone. The calendar was built to cover October 2026 through December 2027 instead.

Why: banners for holidays that have already passed are useless, and it is one file either way, so the extra year costs nothing and gives real planning runway.

"EU" in the holiday calendar means France, Spain, Greece and Portugal

The European Union is twenty-seven countries with different holidays, so the ticket's "EU" needed a definition. It means France, Spain, Greece and Portugal.

Why: BIBLE section 3 says the site is translated into Vietnamese, Spanish, French, Portuguese and Greek and no others, which maps almost exactly onto the ticket's country list. That is evidence from the repo rather than a guess. The other twenty-three are excluded because a banner in a language the site does not speak is a claim we cannot back.

Every chat walks its operator through close-out when its pill is done

New standard for every chat, approved by YT. When a chat's pill is done and merged, that chat walks its operator through wrapping up, in plain steps with the reason, so nobody is left guessing. The steps the chat gives: (1) archive this chat, (2) open a fresh chat for the next pill. The reason it states: a fresh chat starts with the latest rules and any new commands added since, and nothing is lost because it is all saved in git. The Runner is the safety net — if a chat is closed or a step is missed it catches the task and re-surfaces it. Slacking the operator is the Runner's job, not the finishing chat's.

Why: it prevents the operator getting lost at hand-off, the exact confusion this session hit. Folded into CLAUDE.md's task-flow and close-out sections (rules are propose-only; YT confirms).

Canonical teal is #0f766e

Canonical teal is #0f766e. The logo currently uses #0d9488, which is the outlier to fix later. Every other brand surface uses #0f766e. Unblocks the RME-10 banners.

The RME-10 banners use verdict colours as plain bars, never the verdict emblems

No banner in the RME-10 set uses the verdict emblems (ASSET-008, 009 and 010). Where a verdict colour appears it is a plain accent bar or pill. The asset registry marks the emblems do-not-recolour-or-redraw, and redrawing them at banner scale is what that guard exists to prevent.

Why this is worth recording now that the block is gone: YT originally said in #rme-ops to hold the banners on the emblems until she confirmed the local reels/verdict-*.svg copies were faithful. She has since confirmed them, see [2026-09-21-verdict-emblems-approved.md](2026-09-21-verdict-emblems-approved.md). So using an emblem on a banner is now an option YT can choose, not a blocker. The set as built simply does not use them.

Teal in every banner is #0f766e, per [2026-09-21-canonical-teal.md](2026-09-21-canonical-teal.md). The wordmark is typeset in Manrope rather than the real lockup, because the canonical _BRAND-SYSTEM.md lives on YT's Mac and could not be read from Vy's machine. That one is still open.

Banner house style is saturated ground, big type, high contrast, willing to show the product

Vy was shown six Halloween banner concepts spread across real design axes. She chose three, and every one of them used a saturated brand ground with big type and high contrast. She rejected all three of the pale and restrained options. That is the house style for banners from now on.

Why: it makes future banner work decidable without another round of guessing.

Two deliberate exceptions. Remembrance Day and Dia da Consciencia Negra use a sober layout with no joke and no product line, because the house style must not outrank the occasion.

A related point Vy set on the Christmas banner: decoration alone does not clear the bar. A tree, a Santa and a row of baubles were rejected as pretty but meaningless. The art and the product mechanic have to be the same idea, which is why Santa checks the list twice and sorts it into two piles.

How a standing chat archives when it has no PR of its own

/rme-archivechat step 1 says "confirm the PR merged". That is written for a task chat, where the chat and the deliverable are the same thing. A standing chat (the Tickets chat, the runner) has no PR of its own, so read literally that step means a standing chat can never archive.

The gate for a standing chat is the substance behind that step: nothing it produced is stranded where only that chat knows about it. In practice that means its work product is on a pushed branch, that branch has a PR open or a named owner who has taken it, and the handover has landed. The outgoing Tickets chat met that on 2026-09-21 by handing claude/vigorous-cerf-516814 to its successor, which then rebuilt the content onto vy/tickets-chat-record.

Proposed: /rme-archivechat step 1 should say this outright, so the next standing chat does not have to reason it out from scratch. For YT to confirm, since the skill is hers.

The Email Almanac is mirrored into the repo as a read-only snapshot

The Email Almanac is now mirrored into the repo as a read-only snapshot at 01-library/email-almanac/ (4,095 published questions). The repo copy is the approved source for every email fact: no internet lookups, no model general knowledge, and if a fact is not in the snapshot, stop and ask YT. refresh.sh re-exports and commits after the Hetzner database is edited. The CLAUDE.md rule-1 note was updated to point at the snapshot.

Rejected: the earlier plan to connect Claude read-only to the Hetzner database. Why: the snapshot gives the marketing team and their Claude the one approved source with no Hetzner credentials to hand out.