CASE STUDY · F3 FRAMEWORK IN PRACTICE

NO DOCUMENTATION.
NO BACKUP.
NO PROBLEM.

How MethodFactory rescued a $1B global organization’s undocumented codebase — discovered an active XSS vulnerability, zero accessibility, and no version control — and delivered a fully documented, production-ready component in a single session.

INDUSTRY

Global Professional Organization

SCALE

$1B+ annual revenue · Worldwide operations

SITUATION

Previous agency terminated · Zero documentation handed off

ENGAGEMENT

Emergency technical rescue + ongoing support

1x

XSS VULNERABILITY FOUND & PATCHED

5

CRITICAL ISSUES SURFACED BEFORE TOUCHING CODE

8

DOCUMENTATION ASSETS PRODUCED

1

SESSION · ZERO RE-ONBOARDING GOING FORWARD

01

THE CHALLENGE

When the previous agency was let go, the organization was left holding a live WordPress website they couldn’t safely touch.

The immediate need was straightforward: update a custom Elementor SVG map component to reflect the organization’s new global headquarters location. The only transition document they received? A folder path inside the Elementor components directory and the note: “That’s where you update the map.”

No component documentation. No version control. No developer to call. For the Business and Internet Systems Manager responsible for delivery, this was the scenario no one plans for — a business-critical digital asset that functioned as a black box.

THE RISKS WERE REAL:

Making a change to an undocumented component could silently break it

No one knew what else might be wrong with the codebase

Any new developer brought in would face the same zero-context starting point

The organization’s global digital presence sat on an unknown foundation

02

WHY F3 EXISTS: THE PROBLEMS THAT FORCED A NEW METHODOLOGY

The scenario above is not the exception in AI-assisted development. It is the pattern.

MethodFactory has been working at the intersection of AI tooling and professional software delivery long enough to have seen the same failures repeat — not because developers are careless, but because AI coding and LLMs arrived without the guardrails and methodology they needed to stay focused and productive. The tools were powerful. The process was nonexistent.

MethodFactory built F3 to provide exactly what was missing: the guardrails and methodology that AI-assisted development and LLMs need to reduce developer spin, stay in scope, and produce work that holds up beyond a single session.
These are the six problems that made it necessary:

01

AI sessions lose context — and start over every time
Every time you open a new Claude session, the AI has no memory of what was built before. Without a structured documentation system in place, each session begins from zero. Decisions made three sessions ago are invisible. Code written last week has no story. The developer — human or AI — is flying blind every single time.

02

Scoping is skipped entirely. There is no Spec → Plan → Build phase
AI tools are optimized to start producing output immediately. That instinct is a liability in professional development. Real projects require a Specification phase to define what is being built, a Planning phase to decide how it will be built, and only then a Build phase where code is written. Without F3’s enforced phase gates, AI jumps straight to implementation — building the wrong thing with great confidence and no scope boundary to stop it.

03

The AI thrashes — and no one stops it
When an AI-assisted approach isn’t working, the default behavior is to try again. And again. And again — with small variations, mounting frustration, and an ever-growing pile of broken attempts. In a real-world professional environment, a developer who can’t solve a problem doesn’t spin indefinitely. They stop. They escalate to a senior lead or architect. They discuss the problem, agree on a better approach, and proceed. F3 mechanically enforces this. When repeated failures are detected, the session stops. A review brief is required. Work does not resume until there is a plan.

04

Documentation doesn’t survive past the session
Without a structured system forcing documentation to happen, it doesn’t happen. Not because anyone intends to skip it — but because the AI moves fast, tasks get completed, and documentation feels like something to do later. Later never comes. The next session starts from scratch. The project accumulates capability and loses memory simultaneously.

05

Long development cycles produce zero written record
The longer a development session runs, the more ground is covered — and the more likely that none of it gets written down. F3 solves this with enforced documentation checkpoints at defined intervals, ensuring that extended sessions don’t end with a pile of changes and no record of what was done or why.

06

Production standards are invisible to AI
AI builds what works. It does not build what is production-ready unless something forces it to. Security, accessibility, error handling, and logging are simply absent from default AI output — not because the AI can’t address them, but because nothing in the tool layer requires them. A developer under deadline pressure skips them. An AI without guardrails never considers them at all. F3 treats these four standards as non-negotiable pillars on every engagement — enforced throughout every session, not checked as an afterthought at the end. The XSS vulnerability and zero accessibility handling discovered in this engagement are not anomalies. They are what AI-assisted development produces by default when no Production Standards are enforced.

MethodFactory built F3 because the industry needed professional guardrails and methodology — and none existed. F3 provides the guardrails and structure that keep AI-assisted development focused, bounded, and productive: a Spec before a Plan, a Plan before a Build, enforced stops before spinning turns into damage, Production Standards enforced throughout every session, a Commit Gate that ensures nothing is committed without a complete record, a Handoff Readiness standard that keeps the project in a state any developer can pick up at any time, and an Existing Project Protocol that ensures inherited codebases are fully understood and documented before a single line of code is changed. That last point matters most for the majority of real-world engagements — because most teams will implement F3 on a system that already exists, not one they built from scratch.

03

THE METHODFACTORY APPROACH: F3 BEFORE A SINGLE LINE OF CODE

MethodFactory’s first move was not to open the component and start editing. It was to establish a foundation. Using the F3 Framework (Foundation-First Framework) — MethodFactory’s proprietary AI-assisted development methodology — the team set up a structured, documented, and auditable development environment before any changes were made.

SETUP STEPS:

01

Downloaded the full project files to a local directory

02

Configured VS Code to point to that directory as the project root

03

Activated Claude Code within the project environment

04

Ran node setup-f3.js — the self-contained F3 installer, deploying the full framework file structure in a single command

05

Pasted the F3 Existing Project Prompt into Claude Code — a structured four-phase onboarding sequence that converts any inherited codebase into a fully F3-compliant, documented baseline. Nothing is changed until the developer approves.

The Existing Project Prompt runs four phases: assess the current state, reverse-engineer a retroactive SPEC.md and PLAN.md, create all eight docs/ files from real codebase analysis (not empty templates), and present findings for approval. The entire conversion happens in a single session.

THE FOUNDATION DOCUMENT: PROJECT SOURCE OF TRUTH

Before development began, the project received its first-ever Foundation Document — the cornerstone deliverable of every F3 engagement:

Brief Project Brief
Purpose of the codebase, business context, and intended functionality of the Elementor map component
Stack Full Tech Stack Inventory
WordPress version, Elementor version, WP Engine hosting environment, plugin dependencies, and custom component structure
Scope Scope Definition
What is in scope for active development, what is legacy, and what the boundaries of safe modification are
Risk Identified Risk Surface
Plain-language summary of every area flagged during the audit, with risk level and recommended action

04

DISCOVERY: WHAT WAS ACTUALLY IN THE CODEBASE

The F3 Existing Project analysis surfaced issues that no one knew existed — all logged with context, location, and remediation path before a single production change was made:

FINDING RISK LEVEL STATUS BEFORE F3
XSS (Cross-Site Scripting) Vulnerability CRITICAL Unknown / Unpatched
Dead and Legacy Files MEDIUM Present / Not Removed
No Accessibility Handling Absent
Zero Component Documentation HIGH None
No Version Control History HIGH None

For the Business and Internet Systems Manager, this discovery phase alone delivered immediate value: the organization now had a clear picture of what it actually owned, what was broken, and what the risk exposure was.

05

EXECUTION: FIX, DOCUMENT, DELIVER

With the foundation established and issues inventoried, the team moved into structured execution under F3’s methodology — every change documented as it was made:

SECURITY

XSS VULNERABILITY PATCHED

The change log was updated with the specific file, nature of the vulnerability, and the remediation applied. Every detail traceable.

CODE HYGIENE

DEAD FILES REMOVED

Legacy files identified, reviewed, and removed. Each removal logged with rationale in the dev log.

ACCESSIBILITY
ARIA STANDARDS ADDED

Baseline accessibility handling added to the component — bringing it in line with F3’s Production Standards.

DELIVERY

MAP COMPONENT UPDATED
The originally requested work — adding the new global HQ map point — completed cleanly on a now-understood, documented codebase.
WHAT F3 DEPLOYED INTO THE PROJECT
LAYER 01 — FRAMEWORK CORE
THE METHODOLOGY FILES
Nine root-level files including CLAUDE.md (session bootstrap — Claude reads this first every session), SPEC.md and PLAN.md enforcing phase gates, and F3_PROMPTS.md containing every structured prompt. Context survives sessions not through AI memory, but through files.
LAYER 02 — MECHANICAL ENFORCEMENT
THE HOOKS THAT RUN

Three scripts in .claude/hooks/ on macOS/Linux and Windows. The Restart Gate intercepts runaway sessions. The Commit Gate (G-07) blocks commits that don’t meet documentation and Production Standards requirements. The Thrash Detector forces a structured stop when spinning is detected.

LAYER 03 — PROJECT DOCUMENTATION
THE LIVING RECORD
Eight structured documents in docs/: architecture, API contracts, tech stack, architecture decision records, crash-recovery checkpoint, dev log, task tracking, and release changelog. Updated every session. The permanent, auditable record of the project.

The session was closed using F3’s Session End Prompt — a structured wrap-up that triggered a final documentation pass. Claude produced a complete summary of every action taken, every file changed, and every decision made. All changes were committed to Git with meaningful, traceable commit messages.

06

WHAT THE PROJECT RECEIVED: F3 DOCUMENTATION ASSETS

Documentation is not a deliverable that comes later in F3 — it is produced as a byproduct of execution. By the time this session closed, the project had a complete documentation suite that did not exist the day before:

DOCUMENT PURPOSE WHEN PRODUCED
FOUNDATION Project brief, tech stack, scope, and risk surface — the permanent source of truth
↳ Initial onboarding
DEV LOG
Session-by-session record of all development activity, decisions, and rationale
↳ Updated every session
CHANGE LOG
Versioned record of every code change — file, nature of change, reason made
↳ Every code change
SESSION END Full account of what was done, what changed, and what was decided in the session ↳ End of every session
GIT HISTORY
Traceable version control tied directly to documented change log entries
↳ End of every session

 

TWO CONTINUITY GUARANTEES F3 DELIVERS

01

ZERO RE-ONBOARDING

Every future development session begins with full project context — no archaeology, no re-onboarding. The next developer, human or AI-assisted, opens the project and is productive immediately.

02

REVIEWABLE AUDIT TRAIL

Every change ever made is traceable. The Business and Internet Systems Manager, a security auditor, a new CTO, or an AI assistant can review the complete history — when, why, and by whom. For organizations at this scale, this is a governance requirement. F3 makes it automatic.

07

THE OUTCOME

What arrived as an undocumented black box was delivered back to the organization as a fully documented, version-controlled, accessible, and secure component.

What the component does and how it’s structured — courtesy of the Foundation Document

What changes were made, when, and why — courtesy of the change log and dev log

Where the map data lives and how to update it — documented in the component spec

Accessibility and security standards in place — logged in the session end summary

Complete version history of every change ever made — committed to Git

The organization moved from “we don’t know what we have” to “we know exactly what we have, how it got here, and how to maintain it” — in a single engagement.

08

WHY THIS MATTERS FOR BUSINESS AND IT SYSTEMS LEADERS

The scenario above is not rare. Developer turnover, agency transitions, and acquired codebases are constant realities for any organization running digital products. The question is not whether you’ll face an undocumented handoff — it’s whether you’ll have a methodology in place to handle it.

F3 and AI-assisted development with Claude Code changes the economics of this problem. What previously required weeks of manual code archaeology — or a full rewrite — can now be executed systematically in a fraction of the time, with documented output that actually improves the project’s long-term maintainability.

MethodFactory brings this capability to organizations that need:

Rescue
Emergency technical rescue on inherited or undocumented projects
Ongoing
Ongoing AI-assisted development with structured methodology and full session documentation
Adopt
A development process that produces documentation as a byproduct of execution, not as an afterthought
READY TO TAKE CONTROL OF YOUR DIGITAL FOUNDATION?

BUILD ON A FOUNDATION THAT HOLDS.

If your organization is running on code that only one person understands — or worse, code that no one fully understands — MethodFactory can help.

WORK WITH METHODFACTORY

EXPLORE THE F3 FRAMEWORK

/ / CLIENT PROFILE

INDUSTRY

Global Professional Org

ANNUAL REVENUE

$1B+

PLATFORM

WordPress · Elementor · WP Engine

DOCS BEFORE F3

None

DOCS AFTER F3

Complete Suite

SESSIONS REQUIRED

1

/ / SESSION TIMELINE

STEP 01

Download files · Setup VS Code · Activate Claude Code

STEP 02

Run node setup-f3.js · Deploy F3 framework

STEP 03

F3 Existing Project Prompt · Full codebase audit

STEP 04

Foundation Document created · Issues logged

STEP 05

XSS patched · Files cleaned · Accessibility added

STEP 06

SVG map component updated · HQ location added

STEP 07

/ / 10 GUARDRAILS APPLIED

G-01
Foundation Before Code
G-02
Thrash Detection
G-03
Scope Enforcement
G-04
Session Close Protocol
G-05
Mid-Session Checkpoints
G-06
Production Standards
G-07
Commit Gate
G-08
Handoff Readiness
G-09
Existing Project Protocol
G-10
Multi-Agent Review Model

/ / ABOUT F3

F3FRAMEWORK.COM

METHODFACTORY.COM