A hard pressure test of our own architecture, before he does it for us
YouChews · written 27 Aug 2026 · status updated 28 Aug · every finding verified against the live repo and accounts, not reasoned about
This is a living document. Three of the eight findings have been closed since it was written; the status column is updated rather than the finding being deleted, so the record of what was wrong survives.
| # | Finding | Status |
|---|---|---|
| 1 | main cannot be protected | Open — needs an Organization or GitHub Team |
| 2 | 592 tests, no CI | Open — design agreed (pull requests only), not built |
| 3 | Our own docs were stale | Closed 28 Aug — count corrected; root cause remains |
| 4 | Instructions locked to one vendor | Closed 27 Aug — AGENTS.md added |
| 5 | 2,520 binaries, no Git LFS | Open — needs a history rewrite |
| 6 | Personal financial data in the repo | Mostly closed 28 Aug — see below for what remains |
| 7 | Lanes are a convention, not a lock | Open — design needed |
| 8 | The record is unstructured prose | Open by choice — watching, not rebuilding |
Brett asked for the plan to be stress-tested by someone assuming Hassan is a genius who will find the holes. So this is written adversarially, against our own work. Every item below was checked against the live system tonight, not reasoned about. Where a check returned something uncomfortable, it is stated as it came back.
The pattern in what follows: the design is sound; the plumbing under it is not ready for a second person. Six of the eight findings are things a strong engineer notices in the first hour.
Asking GitHub to show branch protection on this repo returns, verbatim:
Upgrade to GitHub Pro or make this repository public to enable this feature.— HTTP 403
Branch protection does not exist on a free personal private repository. So a collaborator — or any of the ~80 commits a day flowing from automated sessions — can force-push and rewrite history on main with nothing standing in the way.
This is the second hard argument for a GitHub Organization tonight, alongside the inability to segregate personal files. It is also the cheapest to fix: GitHub Team is about $4 per user per month and turns on protected branches for private repos.
Recommendation: do not leave main unprotected once a second person has write access. Either upgrade or move to an Organization before real collaboration starts.
pytest collects 592 tests. There is no .github/workflows directory — no continuous integration at all. With this commit volume, a change that breaks the suite reaches main silently and the next session inherits it.
And the obvious fix has a trap. GitHub Actions gives 2,000 free minutes a month on private repos. At roughly 80 commits a day, running the suite on every push would exceed that in the first week. So: run CI on pull requests only, not on every push. That also fits the working split we proposed — Brett's Mac on main, Hassan on branches — and gives his contributions an automatic safety check that Brett's do not currently have.
CLAUDE.md stated the suite was "141 green." It is 592 — a number that had been wrong for two weeks, sitting in the very file that exists to prevent drift.
Corrected 28 Aug, with the old figure and its staleness left visible in the file rather than quietly overwritten. But the deeper point stands and is not fixed: anything a document asserts and no check enforces will drift. The repo's own principle says it better than we can — a rule in a document gets broken; a rule in the path gets followed. This finding will recur until a check enforces the count.
Our argument for keeping the brain in files is that it survives a change of vendor, plan or model. Until tonight, every rule lived in CLAUDE.md, which one vendor reads. If Hassan prefers Cursor, Codex, Windsurf or Zed, he would have opened this repo and found no instructions at all.
Fixed tonight: AGENTS.md added at the root. That is the open convention — released by Anthropic in late 2025, now stewarded by the Agentic AI Foundation under the Linux Foundation, adopted across Claude Code, OpenAI Codex, Cursor, VS Code, Gemini CLI, Windsurf, Aider, Zed and 30+ other tools, and present in over 60,000 repositories. It points at CLAUDE.md as authoritative rather than duplicating it, which is the recommended pattern.
This one matters beyond tooling: a standard governed by a foundation rather than a vendor is the same bet as keeping the brain in files. We were making that argument while quietly not following it.
That is why the repository is 5.5 GB and why a clone is a genuine wait. Ad videos and images went into history directly instead of into Git LFS or external storage. Every clone, forever, pays for every video ever committed.
It is fixable only by rewriting history — the same operation that would scrub the personal files from the past (finding 6). If we ever do one, we should do both in the same pass, and now is the cheapest moment it will ever be, because Brett is currently the only person holding a clone. That window closes the moment anyone else clones.
What we found: reimbursements/ held 15 files, plus the cap table, the NikCo co-ownership memo and a tax assessment. JOURNAL.md mentions tax 31 times and medical 9 times with real figures in the prose, so deleting spreadsheets alone would not have been enough.
What we did, 28 Aug: judged all eighteen files individually rather than by folder. Thirteen of fifteen reimbursement files are company financial matters a Chief of Staff should see, as are the cap table and the NikCo material — those stay. Only the medical reconciliation was genuinely personal. Five files (two spreadsheets, one report and two PDFs — three of which a first, folder-scoped pass missed) were moved out of the repository and the filename pattern added to .gitignore.
A separate defect surfaced in the same pass. The tool that mirrors Brett's Claude memories into the repo guarded only on a type: user tag; four memories tagged project carried his tax return and medical deductions straight through. A content-based privacy guard now withholds them, and git log confirms zero commits for all of them — they never entered history.
What is still true, and stated plainly: the removals take those files out of the working tree so nobody stumbles on them. They remain in git history. Reading them now requires deliberate digging rather than a glance — an acceptable risk for a trusted Chief of Staff, and not worth rewriting ~5,000 commits over. Personal GitHub repositories also have exactly one collaborator level, so folder-level permission does not exist; genuine segregation needs a second repository, which is the Organization recommendation above.
tools/lane records who is doing what. Nothing prevents two people from doing the same thing anyway. It was designed for several chats on one machine sharing a staging area — a genuinely different problem from two people on two machines.
The repo's own standard is that a finding is not recorded until something refuses work that violates it. By that standard, lanes are not yet a rule. They are a note.
Structured data does live in data/*.jsonl — bets, ideas, tasks — with the markdown generated from it. That part is right. But the reasoning lives in JOURNAL.md as long narrative, and that is what someone actually needs to understand a decision.
It works today because one person wrote all of it. It is untested as a way for a second person to find out why something was decided six weeks ago. Watch this one; do not pre-emptively rebuild it.
Enterprise-managed MCP connectors do not help us. Anthropic made this generally available on 24 August, and at a glance it looked like the answer to "how does Hassan get API access without being handed keys." It is not. It requires the Enterprise tier and an identity provider (starting with Okta), and the supported connectors are Datadog, Notion, Slack, Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase. None of ours — Windsor, Meta, Shopify, Klaviyo, Higgsfield — are on that list. The secrets problem remains unsolved and the honest answer is still: do not solve it yet, because nothing in Hassan's first two weeks needs those keys.
Artifact sharing is better than we said. The control is at Settings → Claude Code → Capabilities → Artifacts → External sharing, off by default on Team. Off means in-organisation sharing already works — so artifacts published from the org are openable by Hassan today, and only public links are disabled. There are also retention settings under Settings → Data & privacy controls, with separate periods for private and shared artifacts. Leave external sharing off.
| # | Fix | Status | Effort |
|---|---|---|---|
| 1 | AGENTS.md so any agent tool inherits the house rules | Done tonight | — |
| 2 | Privacy guard on the memory mirror | Done tonight | — |
| 3 | Correct titles on every PDF | Done tonight | — |
| 4 | Segregate personal financial data into a second repo | Brett's decision | half a day |
| 5 | Protect main — GitHub Team or an Organization | Brett's decision | 10 min + $4/user |
| 6 | CI on pull requests only (not pushes — minutes budget) | Ready to build | 1 hour |
| 7 | Git LFS or history rewrite for 2,520 binaries | Combine with #4 | half a day, real risk |
| 8 | Make lanes refuse rather than record | Design needed | unknown |
Items 4 and 5 are the same decision wearing two hats: a GitHub Organization. One choice answers both the segregation problem and the unprotected-branch problem. That is the single highest-leverage thing Brett can decide this week.
Not "what do you think of the plan" — specific enough that his answer changes what we build.
That asynchronous is enough. We chose files plus a daily email over a live channel, partly on principle and partly because Brett will not use Slack. That is a real constraint, honestly held — but it means the only shipped product with memory genuinely shared between two people is off the table for us. If Hassan's first week says the loop is too slow, the answer is not to defend the design. It is to reopen the channel question, including the version nobody has priced: one Slack channel used purely as a Claude workbench rather than as a workplace.
Prediction #298: at least three of the eight findings above will be things Hassan independently identifies in his first week, which would tell us the audit was honest rather than flattering. Wrong if he finds fewer than three of them, or if his top concern is something not on this list at all — in which case we missed the real risk and should say so plainly rather than defending the document.
Verified 27–28 Aug 2026: branch protection by live API call returning 403; test count by pytest collection; CI absence by directory check; binary count and repository size from git; personal-file exposure by tracked-file audit and history search; AGENTS.md adoption, enterprise-managed MCP scope and artifact sharing controls from current vendor documentation.
← All documents