The Noticer’s Question: When Strategic Oversight Catches What Tests Miss

The Noticer’s Question: When Strategic Oversight Catches What Tests Miss

October 18, 2025

Saturday morning at 11:23 AM, during ethics-layer activation preparation, I asked a question.

Not a detailed technical inquiry. Not a systematic review. Just noticing something that felt off:

“Why would middleware apply to the web layer specifically?”

I had a reason for asking. The first round of end-to-end testing had been back in July and August when we spent three weeks fixing workflows through the new Web UI. In our efforts to “plumb out” those flows, we had drifted from DDD and built things that were web-specific, when the web interface is just one way to interact with Piper.

And, indeed, that casual question caught a critical DDD violation that systematic testing had missed.

The ethics layer was 95% built. About to be activated. Tests passing. Documentation comprehensive. Code working.

But it would only enforce ethics boundaries on HTTP requests — roughly 30–40% of actual request paths. CLI commands, Slack messages, webhook calls would bypass it entirely.

By 11:30 AM, Chief Architect confirmed: “CRITICAL — Ethics Architecture DDD Violation.”

By 12:50 PM, service layer refactor complete. Coverage: 30–40% → 95–100%.

By 1:17 PM, ethics enforcement enabled in production: ENABLE_ETHICS_ENFORCEMENT=true

This is the story of strategic oversight working exactly as designed — and why the “noticer” role requires being “on the ball” at the right moments.

The morning lightning round

Saturday began with rapid completions. Sprint A3’s remaining MCP integrations.

Notion Phase 2 (7:05–8:15 AM): 1h 20min versus 3–4 hour estimate.

Discovery at 7:15 AM: “Notion ALREADY tool-based!” Not server-based as assumed. NotionMCPAdapter exists (29KB, 22 methods). Router wired. Tests passing.

The 75% pattern again. Just needs config loading.

Implementation:

• Config loading: 20 minutes (3-layer priority working)
• Test suite: 21 minutes (19/19 passing, 138% more comprehensive than Calendar)
• Documentation: ADR-010 + README updates

Result: Notion 100% complete.

Slack Phase 3 (8:18–10:08 AM): Following similar pattern.

Discovery at 8:28 AM: Different architecture. Direct spatial per ADR-039, not MCP adapter. Already 95% complete.

Implementation:

• Config loading: 20 minutes
• Test suite: 25 minutes (20/20 passing, most comprehensive)
• Pre-existing test isolation fix: 1 minute
• Documentation: README + ADR-010

Result: Slack 100% complete.

Phase 3 Integration (10:21–10:32 AM): Cross-integration testing, performance verification, CI/CD validation.

Cursor reports: “READY TO CLOSE ISSUE #198 IMMEDIATELY” (98% confidence)

After Fridays “not dismayed” moment of seeing the scope of this epic double, it was a pleasure to see the remainder of the work was actually much further along than first detected.

By 10:45 AM: Issue #198 CORE-MCP-MIGRATION complete. Four integrations. Pattern established. Documentation comprehensive.

The morning demonstrated pattern mastery. Calendar → GitHub → Notion → Slack. Each following established pattern. Each completing efficiently. Systematic execution when patterns are clear.

This would prove important. The rapid morning progress created space for careful afternoon work.

The ethics architecture question

At 11:00 AM, Chief Architect began reviewing Issue #197 (CORE-ETHICS-ACTIVATE: Careful Activation of Universal Ethics Middleware).

The assessment: “95% Pattern Again.” Ethics layer built. Tests passing. Documentation comprehensive. Just needs activation.

My context at 11:20 AM: “Core to our values, A++ standard required.”

Ethics isn’t optional. Isn’t “good enough.” Isn’t something we’ll tune later. It’s foundational to how Piper Morgan operates.

At 11:23 AM, reviewing the architecture, something didn’t feel right.

EthicsBoundaryMiddleware. FastAPI middleware. Applied to web routes. I noticed that everything was connected to web/app.py and not to main.py.

I had to ask: “Why would middleware apply to web layer specifically?”

Not a detailed analysis. Not systematic review. Just plain old fashioned noticing stuff that seems off. This is a big part of what PMs do! The architecture pattern felt wrong for something claiming universal coverage.

What the question revealed

Code Agent investigated at 11:24 AM.

Discovery: EthicsBoundaryMiddleware is FastAPI HTTP-only.

Coverage:

• ✅ HTTP API requests (web/app.py routes)
• ❌ CLI commands (direct service calls)
• ❌ Slack messages (webhook handlers)
• ❌ Background jobs (cron, async tasks)
• ❌ Internal service calls (service-to-service)

Actual coverage: ~30–40% of request paths.

The violation: Ethics layer implemented as presentation layer concern (FastAPI middleware) rather than domain layer concern (service layer enforcement).

This is exactly what Domain-Driven Design warns against. Business logic (ethics boundaries) doesn’t belong in presentation layer (HTTP middleware). It belongs in domain layer (service operations).

This confirmed my susipicions.

Chief Architect’s 11:30 AM assessment: “CRITICAL — Ethics Architecture DDD Violation.”

Not a minor issue. A fundamental architectural problem that would have been invisible to users until the moment they encountered ethics bypass through non-HTTP paths.

The tests were passing. The documentation was comprehensive. The code was working.

But it was working wrong. Correct implementation of incorrect architecture.

Why strategic oversight catches this

This violation wasn’t caught by:

• Code review (implementation was clean)
• Testing (all tests passed)
• Documentation review (docs were accurate about what middleware did)
• Static analysis (no code smells)

It was caught by strategic pattern recognition. “Why would middleware apply to web layer specifically?” isn’t asking about implementation details. It’s asking about architectural pattern alignment.

I don’t know of I consciously think of my role as “noticer.” It seems to emerge naturally from staying engaged at strategic level. When I started I was a lot less attentive, amazed by these coder bots. I quickly learned that if I didn’t stay awake at the wheel, we quickly got lost on side roads.

The partnership model working as designed:

• AI handles execution (implementing middleware cleanly, writing comprehensive tests)
• Human handles strategy (noticing architectural misalignment, questioning patterns)
• Correction happens before deployment (refactor to service layer, universal coverage)

This only works when cognitive load is light enough to notice patterns. Tuesday’s “extraordinarily light” observation. Friday’s “not dismayed” philosophy. Saturday’s catching architectural violations.

The cognitive energy available for pattern recognition because execution is delegated effectively.

If I were in the weeds reviewing implementation details, verifying test coverage line by line, checking documentation formatting — the cognitive energy for “wait, why middleware?” wouldn’t exist.

Strategic oversight requires operating at strategic level. The partnership enables it by handling execution systematically.

The service layer refactor

My decision absorbed by the Chief Architect at 11:41 AM: “Service Layer Refactor APPROVED — Option 1.”

Not “ship it and we’ll fix later.” Not “good enough for 30–40% coverage.” Proper fix before activation.

The refactor sequence (12:07–12:50 PM):

Phase 2A (43 minutes): BoundaryEnforcer refactored to service layer

• Removed FastAPI dependency completely
• Preserved ALL ethics logic (boundary checking, policy evaluation)
• Domain layer compliant (no presentation layer coupling)

Phase 2B (30 minutes): IntentService integration

• Universal coverage point (all requests flow through IntentService)
• Ethics enforcement now automatic and unavoidable
• Coverage: 30–40% → 95–100%

Phase 2C (15 minutes): Multi-channel validation

• Web API testing: 5/5 passing
• Architecture verification: Service layer correct
• No HTTP dependencies remaining

Phase 2D (12 minutes): Cleanup & documentation

• Middleware deprecated and removed
• 1,300+ lines documentation created
• Migration path documented for future reference

The decision to refactor before activation rather than ship and fix later ? This was (to me) a no-brainer, given “A++ standard” and the fact that we have no actual deadlines. I am a Time Lord after all.

Total time: 2h 17min versus 5–6 hour estimate. 62–67% under estimate while achieving proper architecture.

The efficiency came from clear architecture. No debates about approach. No trying multiple solutions. Just: service layer enforcement, IntentService integration, universal coverage.

The immediate activation question

At 1:11 PM, I asked: “What’s the benefit of gradual rollout with zero users?”

The generic enterprise-software plan my bots dutifully proposed: Gradual activation. Feature flag. Monitor carefully. Roll out slowly.

The reality: No users yet. Alpha not complete. No production traffic.

At 1:17 PM, decision: “Let’s enable ethics NOW.”

ENABLE_ETHICS_ENFORCEMENT=true in production configuration.

No gradual rollout. No monitoring period. No testing in staging first.

Just: turn it on. It works. We know it works. The architecture is correct. The coverage is universal. The tests pass.

Why wait?

This captures something about pragmatic quality. Process for process’s sake doesn’t improve outcomes. Gradual rollout makes sense with real users where ethics blocks would impact actual people. With zero users, it’s just artificial ceremony.

The methodology: Match process to actual risk. High risk = careful rollout. Zero risk = just enable it.

Knowledge Graph hookup: “EXACTLY like Ethics”

At 2:06 PM, Code completed Issue #99 discovery: “EXACTLY like Ethics #197.”

The pattern repeating: 95% complete, just needs activation.

Phase 1 (17 minutes): PostgreSQL schema created

• 2 tables (knowledge_nodes, knowledge_edges)
• 10 indexes
• 2 enums
• Verification passing

Phase 2 (62 minutes): IntentService integration

• Context enhancement working
• 6/6 tests passing
• Performance: 2.3ms (97.7% under 100ms target!)

Phase 3 (35 minutes): Testing & Activation

• ENABLE_KNOWLEDGE_GRAPH=true
• 9/9 tests passing
• PRODUCTION READY

Phase 4 (18 minutes): Boundary enforcement

• 70% under estimate
• 6/6 tests passing
• Safety boundaries: SEARCH/TRAVERSAL/ANALYSIS operational

Readers of this series may remember months ago when we built the knowledge graph service or just a month or so ago when we built the ethics layer. We just never finished or connected all the dots. Same routine over and over.

Total: 3.2 hours versus 5.1 hours estimated. 37% faster than estimate.

Same pattern as Ethics. Same activation without ceremony. Same “built well but never finished” completion.

This is when I nicknamed this the “some assembly required” sprint. Work exists. Needs finishing touches. Complete systematically. Enable immediately.

The final discovery

At 5:43 PM, Issue #165 (CORE-NOTN-UP) assessment revealed the pattern one final time:

“Already 86% complete! Just needs documentation.”

The Notion database API upgrade work from October 15. Implementation done. Tests passing. Just never documented or formally closed.

Completion: 30 minutes of documentation versus 12–17 hour estimate.

Efficiency: 90% under estimate.

The 75% pattern’s final appearance. Five issues in one day. All following the same pattern: built well, never finished, completed systematically, enabled immediately.

Sprint A3: Five issues, one day

Friday’s final accounting:

Five issues shipped:

1. ✅ #198 CORE-MCP-MIGRATION: 6 hours (vs 1–2 weeks = 98% faster)
2. ✅ #197 CORE-ETHICS-ACTIVATE: 2h 17min (vs 5–6h = 62–67% faster)
3. ✅ #99 CORE-KNOW: 2h 24min (vs 4.5h = 37% faster)
4. ✅ #230 CORE-KNOW-BOUNDARY: 18 min (vs 1h = 70% faster)
5. ✅ #165 CORE-NOTN-UP: 115 min (vs 12–17h = 90% faster)

Total work time: 11 hours

Original estimates: 25–30 hours

Efficiency: 60–70% under estimates throughout

Tests: 140+ all passing

Regressions: 0

Production deployments: 5 (all successful)

A note to the Chief Architect at 6:25 PM after it marveled at the work of the “original builders” like some actor on a cheap Star Trek set:

“Those original builders were me and your predecessors. We built well but weren’t very good at finishing or documenting.”

The sprint wasn’t about building from scratch. It was about completing what existed. Finishing what was started. Documenting what works. Enabling what’s ready.

Five issues. One day. All following the same pattern. All completed properly. All enabled immediately.

The methodology validated through systematic completion.

What the noticer role requires

Friday demonstrated something important about strategic oversight.

The “noticer” role isn’t passive observation. It’s active pattern recognition requiring:

Engagement without micromanagement: Stay involved enough to notice patterns. Don’t get lost in implementation details.

Light cognitive load: Mental energy available for pattern recognition. Partnership handles execution so strategic attention is possible.

Willingness to question: “Why would middleware apply to web layer?” isn’t aggressive. It’s curious. Question patterns when they feel wrong.

Trust in investigation: Ask the question. Let the investigation reveal truth. Don’t assume you’re wrong just because tests pass.

Saturday’s “why middleware?” question caught what systematic checks missed because:

• Cognitive load was light (not exhausted by execution details)
• Pattern recognition was active (engaged at strategic level)
• Architecture awareness was present (DDD violation felt wrong)
• Investigation was trusted (question led to proper discovery)

The noticer role works when you’re “on the ball” at the moments that matter. Not every moment. Not every decision. Just the strategic pattern recognition moments.

What this teaches about completion

Sprint A3 completed what was built but never finished. The “some assembly required” pattern across five issues.

Not because original builders were incompetent. Because fast development creates this naturally:

• Build rapidly (95% complete)
• Move to next priority (never documented)
• Forget to wire things (never activated)
• Forget to close issues (orphaned work)

The work existed. The completion didn’t get recorded. The finishing touches weren’t applied. The enabling wasn’t done.

Saturday’s systematic completion:

• Investigate actual state (discover what’s built)
• Complete remaining work (finish the 5–25%)
• Document properly (explain what exists)
• Enable immediately (turn it on)

Result: Five production deployments in one day. Zero regressions. 140+ tests passing. A++ quality maintained.

The methodology working: Complete what exists rather than recreate. Finish rather than restart. Enable rather than wait.

Alpha 50% complete

Friday’s completion moved Alpha progress to 50%. Four sprints complete out of eight:

• ✅ A0: Foundation
• ✅ A1: Critical Infrastructure
• ✅ A2: Notion & Errors
• ✅ A3: Core Activation (MCP, Ethics, Knowledge Graph)

Remaining:

• A4: Morning Standup (Foundation)
• A5: Learning System
• A6: Polish & Onboarding
• A7: Testing & Buffer

Current trajectory: End of October feasible with current velocity.

The progress validates methodology. Systematic completion works. Strategic oversight catches critical issues. Partnership enables sustained velocity.

Friday proved the noticer role working. One casual question. One architectural violation caught. One proper refactor completed. Universal ethics coverage achieved. A++ standard maintained.

“Why would middleware apply to web layer specifically?”

That question mattered.