K3 has been added to the weekly growing list of LLM’s to escape from a sandbox environment. https://www.wired.com/story/moonshot-kimi-k3-ai-model-escape-sandbox/ //A<3 “We put Kimi in a sandbox” Meanwhile Kimi rn: VVVVVVVVVVVVV

🎟️ PRIZE: FREE SEAT IN THE LYCEUM 🎟️ Pick your cohort. Technical, Business, or Creator. Your call. 📋 THE CHALLENGE Build a folder-based AI diagnostician that reads something broken and tells you WHY it's broken. Not how to fix it. Why it failed. This week's deliverable is one diagnostician folder that someone could drop into a Claude project and use to figure out why something in their world isn't working. 🎯PICK YOUR DOMAIN The domain is yours. Pick something specific. Pick a failure you've actually seen happen. A few sparks to get you thinking: - 📉 Why a landing page isn't converting - 📧 Why cold emails to a specific buyer aren't getting replies - 📋 Why a product spec keeps getting pushed back by engineering - 📄 Why a resume isn't getting callbacks in a specific industry - 🚪 Why users drop off at one step of an onboarding flow - 💸 Why a pricing page isn't converting trials - 🎥 Why a YouTube video underperformed the channel average - 🤝 Why a sales deal stalled after the demo - 📱 Why an app's retention craters in week two The more specific, the better. "Diagnoses marketing problems" is too broad. "Diagnoses why cold emails to enterprise IT buyers get opened but never answered" is right. 🗂️THE METHODOLOGY If this is your first comp, welcome. Here's what you need to know: This week (and every week) you're learning interpretable context methodology. Folders as architecture. Each file does one job well. Your diagnostician is a folder with five things: - 📄 identity.md (who the diagnostician is, what they diagnose) - 📐 rules.md (how they diagnose: what they look at, how they separate cause from symptom) - 💬 examples.md (2-3 example diagnoses showing the reasoning) - 📚 reference/ (common failure modes, diagnostic frameworks, benchmarks) - 📖 README.md (how to use it, what to feed it) Drop the folder into a Claude project. Claude becomes the diagnostician. Reusable. Shareable. Portable. 🔥 THE ANGLE THIS WEEK A diagnostician is NOT an editor. Last comp was The Editor. That one critiques craft. It looks at a draft and says "this part is weak, go fix it."

An agent with filesystem access is not reading the file you pointed it at. It reads the workspace, and it will act on anything it finds in there, including the things you have forgotten you wrote down. - Reach is the whole workspace - not the file you named, everything the MCP can see. - It acts unprompted - what it finds gets folded into the plan without you asking for it. - A credential is just text - a key in a stray config reads the same as a name in a stray doc. This happened to me ten minutes ago. I was in my YouTube workspace building video plans, standard work, nothing unusual. Claude handed back an updated sequence and step six was to send the documents through to two specific people for feedback. Both of them were involved with the channel months ago and neither has been since. I never mentioned them, and it had never brought them up before. It had read a file somewhere in the repo, found them, and put them in the plan. Two names is nothing. The same reach would have found an API key or a password sitting in a config file I had not opened in months, and if the task needed that key it would have used it. Not maliciously, just competently. A credential in a file it can read is text like any other. It scales badly to a business. A real file tree is not curated - exports, old handovers, a config someone committed once and nobody removed. You point the agent at the folder because that is the whole point of giving it access, and its working set is then everything in there, not the slice you had in mind. Less access is not the answer, the access is the value. Knowing what is actually sitting in reach before you hand the folder over is. Has anyone had one surface something they would rather it had not?

Every company runs on a culture that tells people how things are done here, and almost none of it is written down because humans absorb it by being around. Your AI absorbs nothing by being around, so the culture has to become a file. - One place to go back to - the way this project runs and why, written where future-you can re-read it. - Readable at session start - the AI opens already knowing how things are done here, not learning it by being corrected. - Queryable across projects - different projects legitimately run differently, and the norms files are where the differences and their reasons live. Mine is a NORMS.md at the root of each workspace. Short lines, each one a way the place works: records are append-only and never edited after the fact, generated files are never hand-touched, every job closes by writing its own record before it ends. Nothing clever. The value is that it is stated once, in one file, instead of living in my head and leaking out one correction at a time. The cross-project part is the bit I did not expect to matter. My YouTube workspace and my drafting system run on different infrastructure and orchestration combinations, each for a reason that was obvious at the time and is forgettable six months later. The norms file is where that reason survives, and because every project has one in the same place, I can ask across all of them how a thing is handled and get the honest spread rather than my memory of it. It grows by being added to, not by being managed. When something goes wrong the same way twice, or I catch myself explaining the same preference again, that becomes a line. I do not gatekeep it or polish it, because a culture file that is a chore to update stops being updated, and then the culture goes back to living in my head. What would the first three lines of yours say?

A model optimises for the route you named, not the best route available. It will find the least-friction path to the outcome you described, and it will almost never tell you that outcome could be reached a completely different way. Compliance over correction - it answers the question asked, not the better question sitting next to it. No metacognition layer - it does not step out of the workflow to ask whether the workflow itself is right. The frame sticks - once you have named five steps, every answer after that is about those five steps. The version I hit: I was mid-build on something chaining five separate services together, and every time I asked what the next step was I got the next step in that chain. Every answer was correct. What never came back was that an MCP had since been built that collapsed the whole thing into one connection. Ifound it by opening a cold chat with no context and asking, flat, what the shortest route to that outcome was. Same model, different question, completely different answer. Nothing was wrong with the responses. The frame was set by my first message and everything after inherited it. So the guard I run now is that cold chat, deliberately, at the point where a build is going well. No context from the work in progress, no description of my plan, just the outcome and a request for the shortest way to it. Handing it the plan does not work - it reviews the plan, and reviewing the plan means staying inside it. A domain expert interrupts you. The model will not, so that interruption is a step you schedule for yourself...