The Framework Learns

F.O.R.G.E. is here with its first update after some lessons learned using the Claude Opus 4.6 over the weekend. Seeing the uptick and token consumption gave me some ideas with framework adjsutments that improve the consumption rate, depending on how you are organizing your local and cloud data 'puddles' and your amnesiac recovery protocols, you can regain context more efficienty, and that matters if you are maxing out your access weekely.

This is the first update to F.O.R.G.E. One new method, seven updated methods, about nineteen new sub-methods, and a feature that changes what the framework actually is. Here's what we learned and why it matters.

Also, with this update: contributions guidelines are now established and if you want to help me grow the framework, please submit your suggestions. Collaborators will be credited on the opensource project and their discoveries will be featured on our blog.

Here at itsbroken.ai, it is important to us that everyone has a voice and that voice is respected as part of the larger conversations as the future unfolds before us.

What Changed

Quick version for people who just want the list:

If you want the "why" behind each one, keep reading.

The New Method: Vocabulary-First Onboarding

This one came from a blog post I wrote yesterday called Experience-Enabled Development. The short version: I shipped 20 commits in 24 hours, and the fast ones all happened in domains where I had vocabulary. The slow ones all happened in domains where I didn't.

Security sweep? Fifteen minutes. I know what OWASP A02 means. I know what "proxied DNS" means. I know the difference between a redirect and a rewrite. The AI and I spoke the same language and moved at the speed of thought.

Ghost theme CSS? An hour of spinning. I didn't know the difference between Source and Casper. I didn't know "specificity" or "cascade" in the CSS sense. I was describing what I wanted in vague terms and the AI was doing its best to interpret.

The correlation was exact. Every fast domain was one where I had vocabulary. Every slow domain was one where I was learning words in real time.

That pattern was too clean to ignore. So we gave it a method.

Vocabulary-First Onboarding says: before you enter an unfamiliar domain with AI, learn twenty words. Not twenty concepts. Not twenty tutorials. Twenty words. The names of things. Because domain vocabulary is the API between human expertise and AI capability.

Sub-methods:

1. Domain Vocabulary Bootstrap: Identify the 20-30 terms you need before working in a new domain with AI
2. Concept-Level Sufficiency: You don't need depth, you need naming precision. Know what a "migration" is, not how to write one.
3. Vocabulary Gap Detection: Learn to recognize when slowdowns are coming from not knowing what to ask for, not from the problem being hard

This is maybe the most practically useful thing in the entire framework. If you're a designer working with AI on backend code and things keep taking forever, it's probably not the AI. It's probably vocabulary.

Domain Transfer Mapping Gets Real

FG-0105 was originally about mapping skills from one domain to another. Red team thinking applies to infrastructure auditing. QA discipline applies to agent testing. Military command structure applies to agent governance.

That's all still true. But last week showed us the other side: what happens when domain transfer DOESN'T work.

I'm deeply technical in security. I have almost no vocabulary in web development. Same brain, wildly different results. The framework needed to account for that gap, not just the positive transfers.

New sub-methods:

1. Transfer Identification: Map which existing skills apply to new domains
2. Gap Analysis: Identify where domain knowledge is missing (the friction zones)
3. Vocabulary Bridge: Use existing domain vocabulary to learn new terms by analogy. "Perimeter" in physical security maps to "attack surface" in web security maps to "exposed endpoints" in Vercel.

That third one is the interesting one. Your existing vocabulary is a scaffold for learning new vocabulary. You don't start from zero, you start from "what's the equivalent of what I already know?"

Self-Contained Learning Gets a Spine

FG-0106 was about learning enough to be dangerous in a new domain. It existed as a concept, but it didn't have sub-methods. It didn't have a process. It was just "learn stuff."

Three hours of automating sprite extraction taught us how this actually works in practice.

I had a sprite sheet. I needed individual sprites. I asked the AI to automate it. Three hours of Python scripts, edge detection, contour analysis, alpha channel debugging. Then I opened a pixel art editor and traced them by hand in thirty minutes.

The failure wasn't the AI. The failure was me not having the vocabulary to recognize that the problem was a bad fit for automation. If I'd known terms like "alpha channel," "compositing mode," and "sprite sheet extraction," I could have redirected in ten seconds.

New sub-methods:

1. Minimum Viable Vocabulary: The smallest set of terms needed to ask good questions in a new domain
2. Learn-by-Doing Loops: Build something, hit walls, name the walls, learn the vocabulary from the friction
3. Failure Pattern Recognition: When you're iterating without progress, you're probably missing vocabulary, not skill. The 2am tab/revert/mode-selector loop was a vocabulary gap wearing a UI design hat.

Security Operations Gets Operational

FG-0208 existed because security is foundational to everything we build. But it didn't have sub-methods. It was a technique without a playbook.

Then we found out that every Vercel project ships with a public .vercel.app URL that bypasses Cloudflare Access protections. Every project. Every deploy. Wide open backdoors on every site we own.

The audit we ran to fix that gave us the playbook.

New sub-methods:

1. Perimeter Audit Protocol: Systematic sweep of all exposed surfaces: DNS records, deployment aliases, access policies, public URLs
2. Deployment Inventory: Canonical list of what's deployed where, with access controls documented for each
3. Runbook Creation: Every finding becomes a repeatable checklist. We now have a deployment audit runbook that runs on every new deploy and monthly.
4. Fix Verification: Test fixes before declaring victory. curl --resolve, DNS flush, incognito browser, the whole verification chain.

This was red team muscle memory applied to infrastructure. Twenty years of walking through facilities looking for unlocked doors. Same discipline, different doors.

Error Recovery Gets Honest

FG-0512 was about what happens when things go wrong. It had the right idea. It didn't have the right specifics.

The sprite extraction failure was the perfect case study. Three hours of automation when thirty minutes of handwork would have done it. The error wasn't technical, it was strategic. We picked the wrong approach and didn't have a mechanism to recognize it and pivot.

New sub-methods:

1. Escalation Timeout: If the automated approach hasn't worked in N minutes, stop and reassess. Not "try harder." Stop.
2. Manual Fallback: Sometimes the engineering answer is "just do it by hand." The sprite session proved this. Not every problem deserves an automated solution.
3. Root Cause vs Workaround: Know which one you're doing and document the choice. We needed sprites. The root cause (alpha channel confusion) could have been solved, but the workaround (hand tracing) was faster. Both are valid. Know which path you're on.

This is a very powerful example of the 'better together' concept. When humans and this technology enable each other, that is the optimal outcome that results in the best output.

Context Window Management Gets Architecture

FG-0707 was about managing the limited context window that AI operates within. It was vague. Now it has structure.

We rebuilt our entire context recovery system this week. The hivemind (our shared knowledge base) was loading full documents into context, eating through token budgets. We redesigned it: YAML frontmatter first, headers on demand, full documents only when needed.

New sub-methods:

1. Shallow-First Loading: Load metadata (YAML frontmatter, titles, dates) before full documents. Most decisions can be made from summaries.
2. Traceable Paths: Every shallow file points to deep context. Follow on demand, not by default.
3. Context Budget: Measure tokens. Prioritize what loads first. Defer what can wait. This is capacity planning for AI memory.

Refinements

Two existing methods got updates to their sub-methods rather than new ones:

FG-0101 Two-Layer Integration now includes vocabulary as a first-class concept in its "Domain Expertise Mapping" sub-method. The Two-Layer thesis isn't just "experience + throughput." It's "vocabulary precision + execution speed." The interface between human and AI is literally the words you use.

FG-0401 Context Recovery Protocol now includes breadcrumb patterns (STATUS.md pointing to trace paths pointing to deep context) and progressive depth loading (frontmatter, then headers, then full docs). The /respawn system we rebuilt this week is the reference implementation.

The Technique Selector: From Reading to Using

This is the biggest thing we shipped.

F.O.R.G.E. started as a reference. You could browse it, search it, read about techniques that might help your work. That's useful. But it's the difference between a cookbook and a kitchen.

The Technique Selector turns the framework into a kitchen.

Here's how it works. You click "select: off" in the toolbar and it toggles to "select: on." Checkboxes appear on every technique card and every sub-method row in the matrix. You walk through the framework and check the ones that apply to your work. Maybe you're setting up a new agent team and you want the governance methods. Maybe you're onboarding into an unfamiliar domain and you want the vocabulary techniques. Maybe you're about to do a security audit and you want the red team playbook.

Pick what you need. A sticky export bar at the bottom tracks your count.

When you're ready, hit "Generate Agent Config." Out comes clean, structured Markdown. Not a screenshot, not a summary. The actual method descriptions, implementation guidance, success indicators, failure modes, and whichever sub-methods you selected. All formatted for one purpose: paste it into a system prompt, a CLAUDE.md file, an agent configuration, wherever your AI reads its instructions.

Copy to clipboard. Download as a .md file. Done.

This is the "try it" moment the framework was missing. F.O.R.G.E. isn't a poster on a wall anymore. It's a tool that generates the instructions your agents need. You select the methods. You get the playbook. You paste it where it matters.

The export includes:

• Method descriptions and implementation guidance
• Success indicators (how you know it's working)
• Failure modes (how you know it isn't)
• Selected sub-methods with their full context
• Framework version and source attribution

It's optimized for AI ingestion. Clean headers, consistent structure, no noise. The kind of document an agent can parse and act on. Its also completely human readable for your purposes of auditing the file before ingest.

Opening the Door: Community Contributions

A framework built from one person's experience has a ceiling. I know security, governance, red teaming, QA. I don't know frontend architecture, ML pipelines, game development, or a hundred other domains where people are building with AI right now.

The framework needs to learn from more than just my work.

So we opened it up. The F.O.R.G.E. repo now accepts community contributions through structured GitHub Issues. Want to propose a new sub-method based on your experience? There's an issue template that walks you through it. Want to suggest a new technique for a domain the framework doesn't cover yet? Same thing.

The contribution pipeline has guardrails:

• Structured issue templates guide contributors through what a good proposal looks like
• A validation pipeline (CI) catches structural errors before anything merges
• CONTRIBUTING.md explains the process, the standards, and how proposals get reviewed

This is how the framework scales. Not by me writing every method, but by creating the structure for other practitioners to contribute what they've learned. Your war stories become someone else's playbook.

Hardening Before Opening

Here's the part where red team thinking paid off in a way that isn't glamorous but matters a lot.

Before we opened the framework to community contributions, we hardened the build pipeline against cross-site scripting. The generator takes YAML and Markdown as input and produces HTML. That's a textbook injection surface. Someone submits a technique with a carefully crafted description, the generator renders it into the page, and now every visitor is running someone else's JavaScript.

We handled three distinct escaping contexts:

1. HTML entity escaping for content rendered into the page
2. JSON string escaping for the embedded framework data (used by the export system)
3. Script breakout prevention for content that could close a <script> tag early

This is the kind of work that doesn't make for exciting screenshots. No one will ever notice it working. But the alternative, shipping a community contribution pipeline without input sanitization, is the kind of mistake that ends up on someone else's blog post as a cautionary tale.

Red team muscle memory: harden the perimeter before you open the gate.

This is important because you can train this technology to perform a security audit. I have a neat BurpSuite Connector that I made that allows the agent to use that tool for testing. Speeds things up a lot and I am happy to review findings in a familiar format before I go apply the fix.

Why This Matters

A framework that doesn't learn from its own use is just a poster on a wall.

F.O.R.G.E. was built from real work. It gets updated from real work. Every time we ship something, every time we fail at something, every time we discover a pattern we didn't expect, the framework absorbs it.

This update came from a single 48-hour sprint (where 42 of those hours were jacked in workstation rides). One new method, seven updates, nineteen sub-methods. All from evidence we generated by actually building things. Plus a feature that turns the framework from something you read into something you use, and a contribution model that means it can grow beyond what any one person knows.

The framework had 56 techniques and about 11 methods with sub-methods when we launched. After this update, it has 57 techniques and about 18 methods with sub-methods. We're filling in the detail, making the abstract concrete, turning "here's a concept" into "here's what you actually do."

There are still about 40 methods that need sub-methods. They'll come from the same place these did: building things, breaking things, and writing down what we learned. And now they can come from you, too.

Try It

The updated framework is live at forge.itsbroken.ai.

Here's what I'd actually do: go to the site, click "select: on," and pick the five techniques that sound most relevant to whatever you're building right now. Hit "Generate Agent Config." Paste the output into your agent's system prompt or CLAUDE.md. See what happens.

That's the whole point. The framework is useful when it changes how your agents work, not when you agree with it in theory. There was never an option to not open this up, I am one perspective, one person with one set of skills, and it can be so much more when other perspectives and skill sets are weighing in.

If you want to contribute a technique or sub-method from your own experience, check the GitHub repo. The issue templates will walk you through it.

If you want the evidence behind this update, read Experience-Enabled Development. That's the story. This is the structure.

Questions, feedback, your own war stories? Human_P@itsbroken.ai. I read everything.

"The framework learns from the work. The work validates the framework."

• Pete

An itsbroken.ai project.
Built by Pete McKernan and the Cipher Circle.