Built something that addresses a gap named in section 6.2 of the ICM paper. https://arxiv.org/abs/2603.16021 Van Clief and McDermott call it "observability without traceability." ICM tells you which files a stage was given. It does not tell you which passage in the output came from which file. If something is wrong, you know what was in the room but you have to read everything and work backward. sem_debug is my attempt at that traceability layer. Point it at a stage output and the declared inputs. It maps every passage back to its source and flags anything with no detectable origin. That unattributed text is where the agent went outside the declared context. I wrote it about a week ago and sat on it because I wasn't sure if I was being a dick. Jake may have already solved this or had something in the works. Figured sharing it was better than sitting on it. Runs inside the ICM workspace structure. Validated on a real pipeline stage. Made the ICM workflow build the tool, because why not. github.com/WBChain3/sem_debug Curious if anyone has experienced the traceability problem, or if Jake has already addressed it somewhere I missed.

Most of what I see in here is about automating tasks. Building workflows, connecting tools, making things run faster. I've been learning all of it and it's clicking.But I kept hitting a wall that I couldn't name for a while. I was using an LLM app as my operating system. Not just for tasks but for decision-making, project navigation, thinking through problems, tracking where things stood across different work. And it kept falling apart. Sessions ended, context disappeared, drift compounded quietly. By the time something felt wrong, I was already deep in the wrong direction. I lost real work to it. The problem wasn't the tool. The problem was the category error. A workflow system automates a process you already understand. You know the steps, you know the inputs and outputs, you want to run it reliably and faster. It's execution. It shines when the process is stable. A reasoning system is what you need before that. It's the thinking partner that helps you figure out what the process should even be, especially when you're building something from scratch and the process doesn't exist yet. You can't automate your way to a decision you haven't made yet. I was treating a reasoning tool like a workflow system. No persistent state, no routing logic, no structure, just conversation. It can't hold a project together. That's not what it's for. So I've been building what I'm calling CoworkOS, based on ICM principles, a folder architecture that gives Claude a stable structure to operate within across sessions. Routing tables, layered context files, memory that persists. The idea is: before you build workflows inside your projects, you might need an operating layer that actually runs the reasoning coherently. I don't know if this is the right approach yet. Still figuring it out. But the distinction feels important, especially if you're newer to this and trying to figure out where to start. Workflows are powerful once you know what you're automating. The reasoning layer is what gets you there.

A recruiter contacted me on LinkedIn on Wednesday. CEO of a crypto startup, $125/hr advisory role, review our product via GitHub repo as the first interview step. The social engineering was top-notch, polished profile with 500+ connections, days of back and forth DMs, the cracks only appeared in hindsight. Friday, I got access to the repo, which felt like a win. With a healthy amount of skepticism, I reviewed the repo with Claude. The codebase looked professional and complete, the README was well structured, and the .json files where malware would normally be hidden came back clean. The payload was buried well enough that Claude and I missed it. Luckily, I decided to enjoy my Friday night and not clone the repo. This is the main reason I want to share my story here: many of us are starting new businesses, and when someone offers you a paid role that seems like the perfect fit, your judgment becomes clouded. I know mine did.Having had more time to think, the inconsistencies started to surface. Lying in bed around midnight on Saturday, the eureka moment happened. This was definitely an elaborate scam. I stayed up all night digging through the repo and gathering evidence to file reports. Here’s what I found: The repo contained a fully operational malware delivery chain: - .vscode/tasks.json configured with runOn: folderOpen — silent code execution the moment you open the folder in VS Code, zero prompt. - .githooks/post-checkout buried under 40 lines of decoy comments, downloading and executing a remote payload from a Vercel server across Mac, Linux, and Windows simultaneously, all output suppressed. - Private key social engineering via the .env.local README instruction, a backup vector in case the malware delivery fails or gets caught  - This is a complex attack chain designed to pass pre-clone inspection. Once you clone it, you’re cooked. I stayed up all night gathering evidence and filing reports: Vercel - both domains, GitHub - account + repo, LinkedIn profile, Basescan wallet flagged, Neynar/Farcaster. Then the big guns: RCMP/CAFC and FBI IC3. But then I started thinking, what tools should I have used to protect myself in this situation?

Dropped a new one for you all. Mike from Urban Pulse let me share footage from his security audit. He vibe coded his whole platform using my routing architecture, then hired me and my team to read every line before he opened it up to high ticket clients. We took our time over many hours. We found three holes that I share here. A Google Maps API key that had already been flagged and locked down by Google. A second cryptographic auth layer the AI built on top of Supabase, which already handles all of this for you. A JWT verification step that never checked the issuer, meaning any valid Supabase token from any project on the internet would have passed. This is what real building and shipping looks like in the AI world. Mike built something that used to take a year and a couple hundred grand. He did it solo. Then he paid engineers to audit it before any customer touched it. Copy his move. If you are vibe coding anything you plan to put in front of paying clients, watch this one.

1. Watch the intro video and introduce yourself in the intro post here 2. Start with The Foundation (free course). Concepts, folder architecture, prompting framework. Everything else builds on this. 3. Check in at the bottom of each lesson. Polls, discussion posts, other members working through the same stuff. Use them. 4. When you're ready to build real things, move to Implementation Playbooks (Level 2). When you're ready to build your own tools, Building Your Stack (Level 3). 5. Post your work. Ask questions. Help others when you can. What are you here to build?