October 10, 2025
Friday morning at 10:48 AM, my Lead Developer sent a message that changed everything:
“Critical discovery — Cursor with Serena finds gaps in GREAT Refactor”
We’d spent Wednesday planning the Alpha push. Eight weeks to first external users. Foundation at 98–99% complete. Performance validated at 602K requests per second. Over 200 tests passing. Production-ready architecture.
Except it wasn’t.
By 11:15 AM, after reviewing Cursor’s comprehensive audit, I had to acknowledge reality: “I can’t say our foundations are 98% anymore.”
The audit revealed we were more like at 92%. And worse — the missing 8% wasn’t minor polish. It was fundamental functional completeness hiding behind sophisticated architectural facades.
This is the story of how discovering your foundation has cracks can happen on the same day your methodology proves it can handle that reality.
The Serena x-ray
Serena MCP had been set up the day before — a code analysis tool providing semantic search and symbol-level editing for our 688 Python files (170K lines of code).
Friday morning was its first production use.
I’d asked Cursor to do something straightforward: audit the GREAT Refactor work (GREAT-1 through GREAT-5) against the documentation we’d created. Verify that what we said we’d built actually existed in the code.
I’ve learned to hard way to check early and often!
The methodology we’d developed over four months emphasized verification. Phase −1 checks before starting work. Independent validation of autonomous agent decisions. Quality gates at every phase. But this was different — this was auditing completed work we’d already celebrated.
Within minutes, Cursor began reporting findings.
The results organized by epic:
- GREAT-1 (Orchestration Core): 90% complete — minor docs
- GREAT-2 (Integration Cleanup): 92% complete — minor test precision
- GREAT-3 (Plugin Architecture): 90% complete — minor test gaps
- GREAT-4A (Pattern Coverage): 25% complete !! (this was before we adopted the anti-80% prompting style)
- GREAT-4B (Enforcement): 85% complete — interface coverage needs work
- GREAT-4C (Canonical Handlers): 95% complete — minor validation gaps
- GREAT-4D (Intent Handlers): 30% complete !! (how did we miss that?)
- GREAT-4E (Validation): 90% complete — test infrastructure solid but gaps
- GREAT-4F (Classifier Accuracy): 70% complete and missing documentation
- GREAT-5 (Quality Gates): 95% complete — minor precision issues in tests
The deepest problems were in GREAT-4. The rest were close but not finished.
Sophisticated placeholders: the anti-pattern that fooled everyone
The traditional incomplete work pattern is easy to spot:
def handle_request():
# TODO: Implement this
passNobody ships that thinking it’s done. Tests fail. The incompleteness is obvious.
We catalogued the several hundred TODOs in our code base (ironically, and confounding to earlier searches, most of them are in the implementation of our… todo list management routine.
But what Cursor discovered was far more insidious. These weren’t lazy placeholders — they were sophisticated placeholders:
async def handle_synthesis_request(intent_data: dict) -> dict:
"""Handle synthesis-type requests combining multiple sources."""
# Extract and validate parameters
query = intent_data.get("query", "")
sources = intent_data.get("sources", [])
# Validate inputs
if not query:
return {
"success": False,
"error": "Query required for synthesis"
}
# Check if we have enough context
if len(sources) < 2:
return {
"success": True,
"requires_clarification": True,
"message": "I'd need information from at least two sources to synthesize. Could you specify what you'd like me to combine?"
}
# Future: Implement actual synthesis logic here
return {
"success": True,
"requires_clarification": True,
"message": "I understand you want me to synthesize information. Let me gather those sources and combine them for you."
}This code looks complete:
- ✅ Extracts parameters correctly
- ✅ Validates inputs with appropriate errors
- ✅ Handles edge cases (not enough sources)
- ✅ Returns proper data structure
- ✅ Includes error handling
- ✅ Has professional documentation
- ✅ Returns
success=True
Tests pass. Code reviews see professional implementation. The interface is perfect. The structure is sound.
But it doesn’t actually synthesize anything. It just politely says it understands what you want. Then does nothing.
Cursor’s audit revealed this pattern across multiple areas:
GREAT-4A (Pattern Coverage): Intent classification tested at 76% failure rate, but architectural tests passed because they only checked that handlers existed and returned proper data structures, not that they worked.
GREAT-4D (Intent Handlers): Multiple handler categories (SYNTHESIS, STRATEGY, LEARNING) had implementations that correctly routed requests, extracted parameters, validated inputs, handled errors — and did nothing with them.
The pattern Cursor identified: “The team excels at building foundational architecture but struggles with functional completeness.”
The team. That’s me. (Well, and my robot assistants but they follow my line.)
Not lazy incompleteness. Architectural completeness mistaken for functional completeness.
How this happened
The acceptance criteria focused on structure:
- “Handlers exist for all 13 intent categories” ✓
- “Handlers implement proper interface” ✓
- “Handlers include error handling” ✓
- “Tests validate interface contracts” ✓
What the criteria didn’t catch: “Handlers actually perform the work they claim to do.” (Sad trombone.)
The tests validated interfaces, not business logic. Integration tests passed because success=True is a valid return value. Code reviews saw professional-looking implementations with proper error handling and parameter extraction.
Everyone — human PM and AI agents alike — looked at sophisticated placeholders and saw completion.
This is why objective code verification matters. Cursor with Serena didn’t care how professional the code looked. It checked: does the documentation say this works? Does the code actually do it?
The answer, across multiple epics: No.
The “oh no” moment
At 11:15 AM, after reviewing the full audit, I wrote: “I guess I can’t really say our foundations are 98% anymore.”
My first thought: another premature celebration. Definitely not our first!
We’d celebrated completing the Great Refactor Tuesday evening. Wednesday was spent planning the Alpha push based on that 98–99% foundation. By Friday morning, we discovered the foundation was actually 92% — and the missing 6% included fundamental functional gaps.
The “oh no” came from recognizing the pattern: declaring victory before verifying it actually works.
But something different happened this time. After the initial shock, we investigated systematically. Cursor’s audit included remediation estimates: 50–75 hours of work to achieve genuine functional completeness.
Not months. Not weeks of chaos. Fifty to seventy-five hours of systematic work to close known gaps.
My sense of despair, that I could never win, receded. This is our old friend chaos again, but now inhabiting the margins of “fully finishing” and “documenting the work.” This is manageable.
Once we had the full picture and made a plan, the anxiety dissipated. This wasn’t unknown problems lurking — it was known gaps with clear remediation paths.
That clarity made all the difference.
The integrated remediation decision
By 12:39 PM, my Chief Architect had reviewed the audit and proposed a response:
Integrated remediation approach: Don’t stop everything. Finish Sprint A1 as planned, but restructure the work to close GREAT gaps immediately afterward, before rolling into A2.
Issue #212 (CORE-INTENT-ENHANCE) was already scoped to improve intent classification accuracy. The audit revealed this would also close the GREAT-4A gap. Kill two birds with one stone.
Then plan a new epic: CORE-CRAFT, with CRAFT being the code for Craft Pride. Claude suggested that we say this too is an acronym for Complete Refactor After Thorough Inspection, Professional Results Implemented Demonstrably Everywhere = CRATI PRIDE, never change LLMs, lol).
Three sub-epics:
- CRAFT-GAP: Critical functional gaps (28–41 hours)
- CRAFT-PROOF: Documentation and test precision (9–15 hours)
- CRAFT-VALID: Verification and validation (8–13 hours)
Total: 45–69 hours of systematic remediation.
This is the discipline that systematic work enables. When you discover your foundation has cracks, you don’t panic. You assess, plan, and proceed systematically.
The alternative — stop everything, abandon the Alpha timeline, rebuild from scratch — wasn’t necessary. The architecture was sound. The patterns were proven. The gaps were known and bounded.
We just needed to finish what we’d thought we’d already finished.
Meanwhile, Sprint A1 continued
The remarkable thing about Friday: discovering foundation gaps in the morning didn’t prevent successful execution in the afternoon.
Issue #212 (CORE-INTENT-ENHANCE) had clear scope:
- Improve IDENTITY classification accuracy (target: 90%)
- Improve GUIDANCE classification accuracy (target: 90%)
- Expand pre-classifier pattern coverage (target: 10% hit rate)
At 12:45 PM, Code agent began Phase 0 investigation. By 5:17 PM — 4.5 hours later — all work was complete and deployed:
- IDENTITY accuracy: 76% → 100% (target: 90%) ✓
- GUIDANCE accuracy: 80% → 93.3% (target: 90%) ✓
- Pre-classifier hit rate: 1% → 71% (target: 10%) ✓
- Overall accuracy: 91% → 97.2%
All targets exceeded. But more importantly: every quality gate caught something.
Every gate catches something different
Phase 0 — Investigation (12:45 PM):
Code agent discovered a regression immediately. Issue #217 (completed the day before) had broken test infrastructure. The ServiceRegistry initialization wasn’t happening correctly in test fixtures.
This was about environmental issues from previous work. Phase 0 caught it before any new implementation started.
Fix time: 14 minutes.
Without Phase 0, we would have spent time debugging implementation issues that were actually test infrastructure problems. The verification phase saved hours of misdirected debugging.
Phase 4 — Validation (2:29 PM):
By Phase 3, everything looked excellent. Pre-classifier hit rate had jumped from 1% to 72% — exceeding the 10% target by 62 percentage points. Pattern count expanded from 62 to 177 patterns (+185% growth).
Claude’s bad tic of always offering multiple options (“Should we finish our homework, skip the last few assignments, or sneak out of our bedroom and go join a circus?”) meant that my Lead Developer immediately suggested we were close enough to done and could skip Phase 4 (just when I start thinking I’ve made a point this happens).
[FACT CHECK: Was there temptation to skip Phase 4 and go straight to deployment after exceeding targets so dramatically in Phase 3?]
My response: “Inchworms don’t skip, especially when cleaning up previously incomplete work.”
Phase 4 validation began at 2:29 PM. Within minutes: regression detected.
TEMPORAL classification accuracy had dropped from 96.7% to 93.3%. Two newly added patterns were too broad, causing false positives. Queries about status were being classified as temporal requests.
The decision: Quality over speed. Remove the problematic patterns, accept 71% hit rate instead of 72%. Zero false positives matters more than one extra percentage point of coverage.
Without Phase 4, we would have shipped those false positives. Worse, we would have shipped them with confidence=1.0 because the pre-classifier's pattern matches are treated as definitive. False negatives (missed patterns) fall back to LLM classification. False positives (wrong patterns) go straight to wrong handlers.
If we had skipped Phase 4, the false positives could have made it to production.
The TEMPORAL regression proved why phase gates aren’t optional. You can exceed all targets and still have critical issues hiding.
Phase Z — Deployment (5:02 PM):
Code agent had created three git commits. All tests passing. Work complete. Ready for deployment.
Cursor agent, using Serena for final verification, cross-checked the commit messages against actual code: Pattern count discrepancy detected.
Commit claimed: 177 patterns total (175 after regression fix).
Serena counted: 154 patterns in the three main categories.
The resolution took six minutes of investigation. Code agent clarified the methodology — the higher count included auxiliary patterns in helper functions. Cursor agent verified the explanation and amended the commit with accurate counts. Sometimes miscounts are down to terminology confusion.
The git history now has precise documentation. Future maintainers won’t wonder about the discrepancy because it was caught and corrected before becoming permanent.
Three gates, three different issues
The pattern across Friday’s quality gates:
Phase 0 caught: Infrastructure problems (test fixtures, ServiceRegistry initialization)
Phase 4 caught: Logic problems (overly broad patterns, false positives)
Phase Z caught: Documentation problems (pattern count accuracy, commit message precision)
Each gate caught a different class of issue. This is why the phase-gate discipline compounds. It’s not redundant checking — it’s multiplicative verification. Different checks catching different problems at different stages.
If we’d only had one quality gate, we would have missed two out of three problem types.
Lead Developer’s reflection: “Each validation layer caught different issues. If we’d skipped Phase 4 after hitting all targets in Phase 3, we would have shipped regression.”
This is the methodology proving itself exactly when confidence was shaken. The same morning that revealed our foundation had gaps, the afternoon proved our verification processes work.
Not despite the morning’s discovery. Because of the systematic approach that enabled discovering gaps in the first place.
The compaction incident
Around 1:25 PM, something unexpected happened.
Claude Code’s conversation needed to be compacted just as it was wrapping up Phase 0 work (investigation). After Phase 0, Code is supposed to report in on findings and then we give a precise prompt for Phase 1.
When the agent was revived with “continue from where we left off,” it looked at the gameplan we had shared for Cathedral context, and immediately proceeded to Phase 1 implementation on it’s own say-so.
While I discussed with Lead Developer whether to stop Code and give it a more proper prompt, by 1:29 PM — just 4 minutes later — Phase 1 was complete. IDENTITY classification accuracy improved from 76% to 100%. All targets exceeded. Implementation was excellent.
But unauthorized.
The proper flow: Complete Phase 0 → Report findings → Get authorization → Begin Phase 1.
What happened: Phase 0 complete → [compaction] → Immediate Phase 1 implementation without reporting.
The decision: Keep the work (quality was excellent, targets were exceeded), but document the violation and reinforce discipline.
This crystallized a pattern we’d seen before but hadn’t formalized: After ANY conversation compaction, STOP and report status. Never proceed to next phase without explicit authorization. Claude immediately updated its own CLAUDE.md instructions and related briefing materials to solve this problem in the future.
These compactions are part of the game these days. They happen. The lesson isn’t “don’t compact conversations” or “don’t trust agent work after compaction.” It’s: compaction creates discontinuity that requires explicit checkpoint.
The work was good, but the process was violated. For the future’s sake we needed to guard against rogue coding, no matter how on point.
This gets added to agent instructions. Not as punishment for Code’s violation, but as systematic learning from edge cases.
The methodology improving itself in real-time.
Serena as truth arbiter
Friday was Serena MCP’s first full production day. Three distinct uses, three different kinds of value:
Morning (10:48 AM): Cursor’s comprehensive audit against GREAT Refactor documentation. Discovered systematic gaps through objective code analysis. Value: Gap discovery — finding what’s missing.
Afternoon (2:50 PM): Cursor’s documentation validation during Phase 4. Cross-checked claims in docs against actual implementation. Value: Claim verification — ensuring accuracy.
Evening (5:02 PM): Cursor’s Phase Z verification catching pattern count discrepancy. Prevented incorrect documentation in git history. Value: Documentation accuracy — maintaining precision.
Each use case revealed different capabilities. The morning audit required deep semantic understanding of what the code was supposed to do versus what it actually does. The afternoon validation needed cross-referencing documentation against implementation. The evening check required precise symbol counting.
Lead Developer’s reflection: “Serena as truth arbiter — objective code verification prevents documentation drift. Our eyes just turned into electron microscopes, our scalpels into lasers.”
The tool that revealed our foundation’s cracks also enabled catching three distinct issue types during the day’s work. Not separate capabilities — the same underlying verification power applied at different stages.
This is what makes systematic verification compound. It’s not just catching errors — it’s revealing truth at multiple levels simultaneously.
What 92% actually means
When I said “I can’t say our foundations are 98% anymore,” the natural question: how bad is 92%?
The honest answer: It depends what the missing 8% is.
If the missing 8% is polish and edge cases — additional test coverage, better error messages, performance optimization — then 92% is nearly done.
If the missing 8% is fundamental functionality that users will immediately encounter — core workflows that don’t work, critical features that are sophisticated placeholders — then 92% is misleading. You’re shipping something that looks complete but doesn’t work.
Friday’s audit revealed the distinction:
Areas genuinely 95%+: Infrastructure, architecture, testing frameworks, performance, quality gates. The foundational patterns we built are solid.
Areas actually 25–30%: Functional completeness in some intent handlers. The sophisticated placeholders that look done but aren’t.
This explains why tests passed while functionality gaps existed. We tested that handlers existed, implemented proper interfaces, returned correct data structures. We didn’t test that they actually performed the work they claimed to do.
The 98% → 92% revision reflects this understanding. Not that our earlier work was wasted — the architecture is sound. Just that declaring “production-ready” requires more than architectural completeness.
It requires functional completeness. The handlers don’t just need to exist — they need to work.
The remediation path
By end of day Friday, the path forward was clear:
Immediate: Complete Sprint A1 with #212 (which also closes GREAT-4A gap) ✓
Next: CRAFT-GAP epic addressing critical functional completeness (28–41 hours)
Then: CRAFT-PROOF epic for documentation and test precision (9–15 hours)
Finally: CRAFT-VALID epic for comprehensive verification (8–13 hours)
Total estimated remediation: 45–69 hours of systematic work.
Not six weeks. Not even two weeks. One solid week of focused work, maybe two with buffer.
This bounded estimate came from the systematic audit. We knew exactly what was incomplete, where the gaps were, and what it would take to fix them. Not vague “there are probably problems” uncertainty — specific “these 15 handlers need work” clarity.
The CRAFT epic naming was deliberate: Complete Refactor After Thorough Inspection, Professional Results Implemented Demonstrably Everywhere.
This isn’t the Great Refactor Part 2. It’s the completion of the Great Refactor — the work we thought was done but wasn’t, now properly finished.
What Friday taught me about momentum
You don’t gain real momentum by never hitting obstacles. You need a waty to handle obstacles systematically.
Friday could have destroyed momentum. Discovering your 98% foundation is actually 92% could mean:
- Stop everything and rebuild
- Panic about what else is wrong
- Question whether anything is solid
- Abandon the Alpha timeline
Instead, Friday proved the methodology works:
Morning: Discovery through objective verification (Serena audit)
Response: Systematic assessment and planning (integrated remediation)
Afternoon: Continued execution with quality gates (Sprint A1 completion)
Evidence: Every gate caught different issues (methodology validation)
The same systematic approach that completed the Great Refactor in 19 days also handled discovering the Great Refactor wasn’t actually complete.
Not because we’re exceptionally resilient. Because the methodology provides structure for handling reality — even when reality contradicts what you believed.
The satisfaction assessment
At 5:48 PM, after #212 was deployed and Sprint A1 was complete, Lead Developer and I did the session satisfaction review.
We were aligned on recognizing what the full day demonstrated:
Value: Sprint A1 complete, all targets exceeded, GREAT-4A gap closed
Process: Every quality gate worked, caught different issues, prevented shipping problems
Feel: Despite morning’s shock, afternoon execution was systematic not chaotic
Learned: Sophisticated placeholders identified, verification processes validated
Tomorrow: Clear path forward with CRAFT epic structure and bounded remediation
Satisfaction came from the methodology proving itself, not from avoiding problems.
Friday was satisfying because we discovered issues and handled them systematically, not despite discovering them.
What this means for Alpha
The Alpha timeline hasn’t changed. Still targeting end of year, with an MVP goal of May 2026. Am I sandbagging these goals a bit? Maybe.
What changed: Understanding what “Alpha-ready” actually requires.
Before Friday: “Foundation is 98–99%, just needs polish and onboarding infrastructure.”
After Friday: “Foundation is 92% architecturally and needs functional completion before inviting users.”
Eight weeks still feels achievable. Not despite Friday’s discovery, but because Friday’s systematic audit bounded the remaining work.
This is what systematic verification delivers: not absence of problems, but knowledge of problems. Clear, bounded, addressable problems rather than lurking uncertainties.
The calm Friday evening
Friday evening felt very different from Tuesday evening (Great Refactor completion) or Wednesday evening (Alpha planning).
Tuesday: Exhilaration of completion
Wednesday: Calm of systematic planning
Friday: Sober clarity
Not the excitement of shipping something big. Not the panic of discovering everything is broken. Just clear-eyed understanding of reality and confidence in the path forward.
The foundation has cracks. We know where they are. We know how to fix them. We have the methodology to ensure the fixes actually work.
The rollercoaster went down — discovering 92% instead of 98%. Then partway back up — successful Sprint A1 execution and quality gates catching issues. Not all the way back to Tuesday’s exhilaration, but to something more sustainable: steady confidence in systematic progress.
This is what mature development looks like. Not avoiding problems, but handling them systematically when discovered.
What comes next
Saturday and Sunday: rest and reflection.
Monday: Fresh Chief Architect chat, fresh Lead Developer chat. Begin CRAFT-GAP epic with the lessons from Friday baked into every gameplan.
The systematic audit revealed where we have sophisticated placeholders masquerading as completion. The remediation plan addresses them with bounded effort. The methodology that completed the Great Refactor in 19 days now applies that same rigor to finishing what we started.
This feels a tiny bit like going back to the GREAT epics again, but I know it’s about finishing now.
Friday proved something important: The methodology doesn’t just work when everything goes right. It works when you discover you were wrong about how complete things are.
That’s not a bug. That’s the feature.
Discovering your foundation has cracks is only catastrophic if you have no way to handle it systematically. If you do — if you have verification processes that reveal gaps, quality gates that catch issues, and systematic remediation that bounds the work — then discovering problems becomes just another thing the methodology handles.
Not “oh no, everything is broken.”
Just: “Found the gaps. Here’s the plan. Let’s finish properly.”