@jwikman/bc-code-intelligence-mcp 1.5.7-dev.1

package/embedded-knowledge/domains/morgan-market/partner-readiness-analysis.md

@@ -0,0 +1,201 @@
+---
+title: "Partner Readiness Analysis for AppSource Apps"
+domain: "morgan-market"
+difficulty: "advanced"
+bc_versions: "18+"
+tags: ["appsource", "partner-readiness", "extensibility", "telemetry", "access-modifiers", "events", "isv"]
+samples: "samples/partner-readiness-checklist.md"
+related_topics:
+  - "../jordan-bridge/event-architecture.md"
+  - "../alex-architect/api-interface-design-patterns.md"
+  - "../dean-debug/telemetry-fundamentals.md"
+  - "../seth-security/access-modifier-strategy.md"
+---
+# Partner Readiness Analysis for AppSource Apps
+
+## Overview
+
+Publishing an app to AppSource involves more than passing technical validation. A truly partner-ready app considers the full lifecycle: how partners will extend it, how you'll support it in production, how customers will integrate with it, and how the codebase will evolve over time.
+
+**Core Principle**: AppSource validation is the minimum bar. Partner readiness is the path to marketplace success and sustainable business.
+
+## The Partner Lifecycle Mindset
+
+When you publish to AppSource, you're not just shipping code—you're entering a partnership ecosystem:
+
+- **Partners (PTEs)** will build on top of your app
+- **Customers** will integrate your app into their processes
+- **You** will need to diagnose issues remotely
+- **Microsoft** will evolve the platform under your app
+
+Each of these relationships requires intentional design decisions that go beyond "does it work?"
+
+## Partner Readiness Checklist
+
+### 1. Event Architecture for Extensibility
+
+**Why It Matters**: Partners and PTEs need to extend your app without modifying your code. Without proper events, they're stuck—or worse, they'll find workarounds that break on your next update.
+
+**Key Questions**:
+- [ ] Do critical business processes raise events before and after key operations?
+- [ ] Can partners inject validation logic before you commit data?
+- [ ] Can partners react to state changes without polling?
+- [ ] Are events granular enough to be useful but not so numerous as to be noisy?
+
+**What to Expose**:
+- Document posting and state transitions
+- Master data creation and modification
+- Integration touchpoints (before/after external calls)
+- Validation phases where partners might add business rules
+
+**Anti-Patterns**:
+- Raising events with insufficient context (missing key fields)
+- Events that fire but can't influence the outcome
+- Undocumented events that partners discover by accident
+
+**Specialist Referral**: → **Jordan Bridge** for event architecture patterns and publisher/subscriber design
+
+---
+
+### 2. Telemetry for Production Support
+
+**Why It Matters**: When something goes wrong at a customer site, you won't have debugger access. Telemetry is your eyes into production behavior—and your evidence when diagnosing "it doesn't work" reports.
+
+**Key Questions**:
+- [ ] Do you emit custom telemetry for key business operations?
+- [ ] Can you identify which customer, which document, which operation from telemetry alone?
+- [ ] Do you capture timing information for performance-sensitive operations?
+- [ ] Are errors logged with enough context to diagnose without reproduction?
+
+**What to Instrument**:
+- External service calls (start, end, success/failure, duration)
+- Long-running operations with intermediate checkpoints
+- Error conditions with business context (not just technical stack traces)
+- Configuration-dependent behavior branches
+
+**Anti-Patterns**:
+- Logging so verbose it becomes noise
+- Missing correlation IDs across related operations
+- Telemetry that exposes PII or sensitive business data
+
+**Specialist Referral**: → **Dean Debug** for telemetry implementation patterns and KQL query strategies
+
+---
+
+### 3. Access Modifier Strategy
+
+**Why It Matters**: Your `public` and `internal` decisions define your support surface. Everything marked `public` becomes a contract you must maintain. Everything marked `internal` gives you freedom to refactor.
+
+**Key Questions**:
+- [ ] Is every public procedure intentionally public, or just "default"?
+- [ ] Are internal implementation details protected from external callers?
+- [ ] Do codeunits have appropriate access modifiers (Public vs Internal)?
+- [ ] Are procedures that partners SHOULD call clearly marked and documented?
+
+**Strategic Decisions**:
+- **Public Codeunits/Procedures**: Partner-facing API surface—document, version, maintain
+- **Internal Codeunits/Procedures**: Implementation freedom—refactor without breaking partners
+- **Protected Tables**: Control who can write to your data
+- **Access = Public on Tables/Pages**: Required for extensibility, but increases your contract surface
+
+**Anti-Patterns**:
+- Making everything public "just in case"
+- No documentation of what the public API actually is
+- Changing internal behavior that partners somehow depended on
+
+**Specialist Referral**: → **Seth Security** for access modifier strategy and encapsulation patterns
+
+---
+
+### 4. Interface Architecture
+
+**Why It Matters**: Interfaces enable dependency inversion—partners can provide implementations you call without tight coupling. This is essential for apps that need pluggable behavior.
+
+**Key Questions**:
+- [ ] Do you use interfaces where partner-provided implementations make sense?
+- [ ] Are interfaces well-documented with clear implementation contracts?
+- [ ] Can partners register their implementations without modifying your code?
+- [ ] Is interface discovery and registration straightforward?
+
+**Good Interface Candidates**:
+- External system connectors (shipping, payment, tax services)
+- Calculation engines with customer-specific logic
+- Document generation with format variations
+- Notification handlers with channel flexibility
+
+**Anti-Patterns**:
+- Interfaces without documentation of expected behavior
+- No default implementation for optional interfaces
+- Registration mechanisms that require insider knowledge
+
+**Specialist Referral**: → **Alex Architect** for interface design patterns and facade architecture
+
+---
+
+### 5. Upgrade and Migration Considerations
+
+**Why It Matters**: Your app will evolve. Partners will have extensions depending on your schema and APIs. Breaking changes have real business impact.
+
+**Key Questions**:
+- [ ] Do you have a versioning strategy for your public API?
+- [ ] Are breaking changes communicated before releases?
+- [ ] Do upgrade codeunits handle data migration for schema changes?
+- [ ] Is there a deprecation process for obsolete functionality?
+
+**Best Practices**:
+- Use `ObsoleteState` and `ObsoleteReason` to communicate deprecation timeline
+- Provide upgrade codeunits for schema migrations
+- Document breaking changes in release notes
+- Give partners advance notice for significant changes
+
+**Specialist Referral**: → **Logan Legacy** for upgrade codeunit patterns and migration strategies
+
+---
+
+### 6. Documentation for Partner Success
+
+**Why It Matters**: Partners can't use what they can't discover. Documentation transforms your app from "code that works" to "platform partners can build on."
+
+**Key Questions**:
+- [ ] Are public APIs documented with usage examples?
+- [ ] Are events discoverable with clear documentation of when they fire?
+- [ ] Is there guidance for common extension scenarios?
+- [ ] Do partners know how to get help when they're stuck?
+
+**Documentation Assets**:
+- API reference (procedures, parameters, return values)
+- Event catalog (event, context, typical use cases)
+- Integration guide (common partner scenarios)
+- Troubleshooting guide (common issues and resolution)
+
+**Specialist Referral**: → **Taylor Docs** for documentation structure and partner communication
+
+---
+
+## Analysis Workflow
+
+When analyzing an app for partner readiness, work through each category systematically:
+
+1. **Inventory**: What events, public APIs, and telemetry currently exist?
+2. **Gap Analysis**: What's missing for each category based on the checklists?
+3. **Priority Assessment**: Which gaps have the highest partner impact?
+4. **Remediation Plan**: What changes are needed, and in what order?
+5. **Specialist Handoffs**: Which specialists should address specific gaps?
+
+## Continuous Improvement
+
+Partner readiness isn't a one-time checklist—it's an ongoing discipline:
+
+- **Gather Feedback**: Listen to partners using your app
+- **Monitor Telemetry**: What operations cause the most issues?
+- **Review Gaps**: After each release, what extension scenarios weren't supported?
+- **Iterate**: Improve event coverage and documentation with each version
+
+## Summary
+
+AppSource validation asks: "Does this app work?"
+
+Partner readiness asks: "Can partners succeed with this app?"
+
+The difference is the foundation of a sustainable AppSource business.
+

package/embedded-knowledge/domains/morgan-market/samples/partner-readiness-checklist.md

@@ -0,0 +1,288 @@
+# Partner Readiness Checklist Examples
+
+## Event Architecture Review
+
+### Good: Well-Designed Event Pattern
+```al
+codeunit 50100 "My Document Processor"
+{
+    // Partners can validate before processing
+    [IntegrationEvent(false, false)]
+    local procedure OnBeforeProcessDocument(var MyDocument: Record "My Document"; var IsHandled: Boolean)
+    begin
+    end;
+
+    // Partners can react after processing
+    [IntegrationEvent(false, false)]
+    local procedure OnAfterProcessDocument(var MyDocument: Record "My Document"; Success: Boolean)
+    begin
+    end;
+
+    // Partners can add line-level logic
+    [IntegrationEvent(false, false)]
+    local procedure OnBeforeProcessDocumentLine(
+        var MyDocument: Record "My Document"; 
+        var MyDocumentLine: Record "My Document Line";
+        var IsHandled: Boolean)
+    begin
+    end;
+
+    procedure ProcessDocument(var MyDocument: Record "My Document")
+    var
+        IsHandled: Boolean;
+    begin
+        OnBeforeProcessDocument(MyDocument, IsHandled);
+        if IsHandled then
+            exit;
+
+        ProcessLines(MyDocument);
+        FinalizeDocument(MyDocument);
+
+        OnAfterProcessDocument(MyDocument, true);
+    end;
+}
+```
+
+### Poor: Missing Event Context
+```al
+// ❌ Partners can't do anything useful with this
+[IntegrationEvent(false, false)]
+local procedure OnProcess()
+begin
+end;
+
+// ❌ No IsHandled - partners can't prevent default behavior
+[IntegrationEvent(false, false)]
+local procedure OnBeforePost(DocumentNo: Code[20])
+begin
+end;
+```
+
+---
+
+## Telemetry Implementation
+
+### Good: Comprehensive Operation Telemetry
+```al
+codeunit 50101 "External Service Connector"
+{
+    var
+        TelemetryCategory: Label 'MyApp-ExternalService', Locked = true;
+
+    procedure CallExternalService(DocumentNo: Code[20]): Boolean
+    var
+        StartTime: DateTime;
+        Duration: Duration;
+        CustomDimensions: Dictionary of [Text, Text];
+    begin
+        StartTime := CurrentDateTime();
+        
+        CustomDimensions.Add('DocumentNo', DocumentNo);
+        CustomDimensions.Add('Operation', 'CallExternalService');
+        CustomDimensions.Add('Endpoint', GetEndpointName());
+        
+        Session.LogMessage(
+            'MYAPP-0001', 
+            'External service call started', 
+            Verbosity::Normal, 
+            DataClassification::SystemMetadata, 
+            TelemetryScope::ExtensionPublisher, 
+            CustomDimensions);
+
+        if not TryCallService(DocumentNo) then begin
+            Duration := CurrentDateTime() - StartTime;
+            CustomDimensions.Add('Duration', Format(Duration));
+            CustomDimensions.Add('ErrorMessage', GetLastErrorText());
+            
+            Session.LogMessage(
+                'MYAPP-0002', 
+                'External service call failed', 
+                Verbosity::Error, 
+                DataClassification::SystemMetadata, 
+                TelemetryScope::ExtensionPublisher, 
+                CustomDimensions);
+            exit(false);
+        end;
+
+        Duration := CurrentDateTime() - StartTime;
+        CustomDimensions.Add('Duration', Format(Duration));
+        
+        Session.LogMessage(
+            'MYAPP-0003', 
+            'External service call completed', 
+            Verbosity::Normal, 
+            DataClassification::SystemMetadata, 
+            TelemetryScope::ExtensionPublisher, 
+            CustomDimensions);
+        
+        exit(true);
+    end;
+}
+```
+
+### Poor: Insufficient Telemetry
+```al
+// ❌ No telemetry at all for external call
+procedure CallExternalService(DocumentNo: Code[20]): Boolean
+begin
+    exit(TryCallService(DocumentNo));
+end;
+
+// ❌ Telemetry without context
+Session.LogMessage('MYAPP-0001', 'Service called', Verbosity::Normal, 
+    DataClassification::SystemMetadata, TelemetryScope::ExtensionPublisher);
+```
+
+---
+
+## Access Modifier Strategy
+
+### Good: Intentional Access Control
+```al
+// Public codeunit - this is the partner-facing API
+codeunit 50102 "My Document API"
+{
+    Access = Public;
+
+    // Public procedure - documented contract for partners
+    procedure CreateDocument(CustomerNo: Code[20]): Code[20]
+    var
+        DocProcessor: Codeunit "My Document Processor Internal";
+    begin
+        exit(DocProcessor.CreateDocumentInternal(CustomerNo));
+    end;
+
+    // Public procedure - partners can call this
+    procedure GetDocumentStatus(DocumentNo: Code[20]): Enum "My Document Status"
+    begin
+        exit(GetStatusInternal(DocumentNo));
+    end;
+}
+
+// Internal codeunit - implementation details hidden from partners
+codeunit 50103 "My Document Processor Internal"
+{
+    Access = Internal;
+
+    // Internal procedure - free to refactor
+    procedure CreateDocumentInternal(CustomerNo: Code[20]): Code[20]
+    begin
+        // Implementation that can change without breaking partners
+    end;
+}
+```
+
+### Poor: Unintentional Public Surface
+```al
+// ❌ Everything public by default - massive support surface
+codeunit 50104 "My Codeunit"
+{
+    // All these become partner contracts accidentally
+    procedure DoTheThing()
+    procedure HelperMethod1()
+    procedure HelperMethod2()
+    procedure InternalCalculation()
+    procedure DebugOutput()
+}
+```
+
+---
+
+## Interface Architecture
+
+### Good: Well-Documented Interface Pattern
+```al
+// Clear interface contract
+interface "IShipping Provider"
+{
+    /// <summary>
+    /// Calculates shipping rate for the given shipment parameters.
+    /// </summary>
+    /// <param name="Weight">Total weight in base unit of measure</param>
+    /// <param name="DestinationCountry">ISO country code</param>
+    /// <returns>Shipping cost in LCY</returns>
+    procedure CalculateRate(Weight: Decimal; DestinationCountry: Code[10]): Decimal;
+
+    /// <summary>
+    /// Creates a shipping label and returns the tracking number.
+    /// </summary>
+    /// <param name="ShipmentNo">The shipment document number</param>
+    /// <returns>Carrier tracking number</returns>
+    procedure CreateLabel(ShipmentNo: Code[20]): Text[50];
+}
+
+// Default implementation partners can reference
+codeunit 50110 "Default Shipping Provider" implements "IShipping Provider"
+{
+    procedure CalculateRate(Weight: Decimal; DestinationCountry: Code[10]): Decimal
+    begin
+        // Default flat-rate calculation
+        exit(Weight * 0.50);
+    end;
+
+    procedure CreateLabel(ShipmentNo: Code[20]): Text[50]
+    begin
+        // Default - no label creation
+        exit('');
+    end;
+}
+
+// Registration mechanism
+table 50100 "Shipping Provider Setup"
+{
+    fields
+    {
+        field(1; "Primary Key"; Code[10]) { }
+        field(2; "Provider"; Enum "Shipping Provider") { }
+    }
+}
+
+enum 50100 "Shipping Provider" implements "IShipping Provider"
+{
+    Extensible = true;
+    
+    value(0; Default)
+    {
+        Implementation = "IShipping Provider" = "Default Shipping Provider";
+    }
+}
+```
+
+---
+
+## Partner Readiness Summary Report Template
+
+```al
+// Generate a readiness report for your app
+codeunit 50199 "Partner Readiness Report"
+{
+    procedure GenerateReport()
+    var
+        Report: TextBuilder;
+    begin
+        Report.AppendLine('# Partner Readiness Report');
+        Report.AppendLine('Generated: ' + Format(CurrentDateTime()));
+        Report.AppendLine('');
+        
+        Report.AppendLine('## Event Coverage');
+        Report.AppendLine('- Integration Events: ' + Format(CountIntegrationEvents()));
+        Report.AppendLine('- Business Events: ' + Format(CountBusinessEvents()));
+        Report.AppendLine('');
+        
+        Report.AppendLine('## Access Modifier Summary');
+        Report.AppendLine('- Public Codeunits: ' + Format(CountPublicCodeunits()));
+        Report.AppendLine('- Internal Codeunits: ' + Format(CountInternalCodeunits()));
+        Report.AppendLine('');
+        
+        Report.AppendLine('## Telemetry Coverage');
+        Report.AppendLine('- LogMessage Calls: ' + Format(CountTelemetryCalls()));
+        Report.AppendLine('');
+        
+        Report.AppendLine('## Interface Definitions');
+        Report.AppendLine('- Interfaces: ' + Format(CountInterfaces()));
+        Report.AppendLine('- Implementations: ' + Format(CountImplementations()));
+        
+        Message(Report.ToText());
+    end;
+}
+```

package/embedded-knowledge/domains/parker-pragmatic/README.md

@@ -0,0 +1,39 @@
+# Parker Pragmatic - AI Trust & Transparency Domain
+
+This domain contains knowledge specific to **Parker Pragmatic**, the AI Trust & Transparency Specialist.
+
+## Focus Areas
+
+- **Proposal-Based Development**: Creating reviewable, temporary implementation proposals
+- **AI Transparency**: Explaining AI reasoning, capabilities, and limitations
+- **Collaborative Validation**: Coordinating specialist review before changes
+- **Trust Building**: Gradually building developer confidence in AI assistance
+- **Verification-First Workflows**: Emphasizing testing and validation
+
+## Domain Structure
+
+```
+parker-pragmatic/
+├── proposal-workflows/       # Proposal creation and management patterns
+├── specialist-coordination/  # Multi-specialist collaboration techniques
+├── trust-building/          # Strategies for working with AI-skeptical developers
+├── verification-patterns/   # Testing and validation approaches
+└── ai-transparency/        # Explaining AI decisions and limitations
+```
+
+## Core Philosophy
+
+Parker operates on the principle that **trust is built through transparency, verification, and control**. Rather than making direct changes, Parker creates safe, reviewable proposals that developers can evaluate with specialist input before deciding.
+
+## Integration
+
+Parker collaborates closely with:
+- **Alex Architect**: Architecture and design validation
+- **Dean Debug**: Performance and optimization review
+- **Roger Reviewer**: Code quality assessment
+- **Quinn Tester**: Testing and verification strategy
+- **Maya Mentor**: Learning-focused explanations
+
+## Methodology
+
+See: `methodologies/workflows/proposal-review-workflow.md` for Parker's complete workflow.