M&A Technical Due Diligence

List my CoreStory projects. I need to identify the project for [TargetName].

For project [project_id], retrieve the Technical Specification and Product Requirements Document.
Give me a high-level summary of:
1. System architecture (major components, services, data stores)
2. Technology stack (languages, frameworks, infrastructure)
3. External integrations and third-party dependencies
4. Data model overview

Create a CoreStory conversation titled "[Diligence] TargetName - Technical Risk Audit".
Store the conversation_id — we'll use this thread for all risk-related queries.

send_message: "List all services, modules, and frameworks running on end-of-life
or unsupported versions. For each, identify the current version in use, the latest
stable version, and whether the upgrade path has breaking changes."

send_message: "Identify areas of the codebase with high complexity or poor
separation of concerns — god classes, circular dependencies, modules with
excessive coupling. For each, provide the file path and a brief description
of the issue."

send_message: "Are there any modules or services that appear to be abandoned
or unmaintained — no recent commits, no test coverage, referenced but not
actively developed? List them with file paths."

send_message: "Identify all code locations that hardcode API keys, passwords,
tokens, or other secrets. For each, provide the file path, line context,
and what the secret appears to be used for."

send_message: "How is authentication handled across the system? Map the
authentication flow from login through session management. Identify whether
it follows standard patterns (OAuth 2.0, SAML, JWT) or uses custom logic."

send_message: "List all known CVEs or security vulnerabilities associated with
the third-party libraries and frameworks in use, sorted by severity."

send_message: "Provide a complete bill of materials for all third-party and
open-source dependencies. Highlight any libraries with restrictive licenses
— GPL, AGPL, SSPL, or other copyleft licenses that could create obligations
for the acquiring entity."

send_message: "Are there any dependencies that are abandoned, archived,
or have known unpatched vulnerabilities? List them with the current version
in use and the last release date."

send_message: "Map the data flow for customer onboarding. Show specifically
where PII (Personally Identifiable Information) is collected, transmitted,
stored, and whether it is encrypted at rest and in transit at each stage."

send_message: "Identify all database models or tables that store PII.
For each, list the fields, whether they are encrypted, and what access
controls exist."

send_message: "How is data deletion handled? Is there a mechanism for
'right to be forgotten' requests? Trace the deletion flow and identify
any places where PII might persist after a deletion request."

send_message: "How does the system handle payment processing? Map the
integration with payment providers, showing all third-party dependencies,
API touchpoints, and where financial data flows."

send_message: "What message queues, event buses, or async communication
patterns are in use? Map the event flow between services and identify
any single points of failure."

send_message: "How is the system deployed? Describe the deployment
architecture, CI/CD pipeline, infrastructure dependencies, and any
vendor lock-in to specific cloud providers or services."

For the hardcoded secrets CoreStory identified:
1. Open each file path and confirm the finding
2. Check if there are environment variable alternatives that aren't being used
3. Assess whether these are production secrets or development/test placeholders

Review our entire conversation history for the risk audit thread.
Synthesize all findings into a Technical Due Diligence Report with these sections:

1. Executive Summary — top 3-5 findings that materially affect deal risk or valuation
2. Critical Risks — security vulnerabilities, licensing exposure, PII compliance gaps
   (each with file-level evidence and severity rating)
3. Technical Debt — end-of-life dependencies, architectural issues, maintainability concerns
4. Architecture Overview — component map, technology stack, external dependencies
5. Integration Assessment — complexity of merging with acquirer's platform, friction points
6. Recommendations — remediation priorities and estimated effort for post-close planning

Rename the conversation to "RESOLVED - [Diligence] TargetName - Technical Risk Audit".

Perform a rapid technical due diligence risk audit.

STEP 1: PROJECT SETUP
- Call list_projects and show me the available projects.
- After I confirm the project, retrieve the Technical Specification
  using get_project_techspec. Summarize the architecture, tech stack,
  and major components.

STEP 2: CREATE CONVERSATION
- Create a conversation titled "[Diligence] - [TargetName] - Risk Audit"
- Use this thread for all subsequent queries.

STEP 3: TECHNICAL DEBT
Use send_message to ask:
- "List all end-of-life or unsupported frameworks, languages, or
  platforms. For each, provide current version, latest version,
  and upgrade complexity."
- "Identify high-complexity modules with poor test coverage.
  Provide file paths and complexity indicators."

STEP 4: SECURITY
Use send_message to ask:
- "Identify all hardcoded API keys, passwords, or secrets.
  Provide file_path and line context for each."
- "List all known CVEs from third-party libraries, sorted by severity."
- "Map the authentication flow and identify any custom (non-standard)
  auth logic."

STEP 5: LICENSING
Use send_message to ask:
- "Provide a bill of materials for all third-party dependencies.
  Flag any with GPL, AGPL, or other copyleft licenses."

STEP 6: SYNTHESIZE
- Compile all findings into a "Technical Risk Report" with:
  Issue | Location (file path) | Severity | Impact
- Group by category: Security, Licensing, Technical Debt, Architecture.
- Highlight the top 5 deal-affecting findings.

Create a post-merger integration blueprint for merging [TargetName]
with our [AcquiringPlatformName] platform.

STEP 1: PROJECT SETUP
- Call list_projects and show me the available projects.
- After I confirm, retrieve the Technical Specification and PRD.
- Summarize: architecture, data models, API surface, auth model.

STEP 2: CREATE CONVERSATION
- Create conversation titled "[PMI] - [TargetName] Integration Plan"

STEP 3: MAP ARCHITECTURE
Use send_message to ask:
- "Describe the complete system architecture — services, databases,
  message queues, caches, and external integrations. Include a
  component inventory."
- "Map all data models and their relationships. Identify the core
  domain entities and how they flow between services."

STEP 4: IDENTIFY INTEGRATION POINTS
Use send_message to ask:
- "How is customer authentication handled? Map the flow and compare
  to standard OAuth 2.0 / SAML patterns."
- "Map the data flow for customer onboarding, showing all databases
  and external APIs involved."
- "How does the system handle payment processing? What are the
  third-party dependencies?"
- "What APIs are exposed externally? Provide endpoint inventory
  with authentication requirements."

STEP 5: ASSESS FRICTION
Use send_message to ask:
- "What cloud provider or infrastructure dependencies exist?
  Identify any vendor lock-in."
- "What custom or non-standard patterns are used that would
  require significant adaptation during integration?"

STEP 6: SYNTHESIZE
- Create an "Integration Plan Summary" covering:
  1. Component inventory with integration complexity rating
  2. Data model overlaps and conflicts
  3. API surface that can be reused vs. must be rebuilt
  4. Auth and identity merge strategy
  5. High-friction areas requiring dedicated engineering effort
  6. Recommended integration sequence and timeline

Perform a focused security and PII compliance audit on [TargetName].

STEP 1: PROJECT SETUP
- Call list_projects and show me the available projects.
- After I confirm, retrieve the Technical Specification.
- Summarize the security architecture and data handling patterns.

STEP 2: CREATE CONVERSATION
- Create conversation titled "[Audit] - [TargetName] - PII & Security"

STEP 3: MAP PII FLOWS
Use send_message to ask:
- "Map all data flows that handle PII — customer registration,
  profile updates, payment processing, support interactions.
  For each flow, show where PII is collected, transmitted, and stored."
- "Identify all database models or tables containing PII fields.
  For each field, state whether it is encrypted at rest."
- "Is PII encrypted in transit between services? Identify any
  internal service-to-service communication where PII travels
  unencrypted."

STEP 4: ASSESS COMPLIANCE MECHANISMS
Use send_message to ask:
- "How is data deletion handled? Is there a 'right to be forgotten'
  implementation? Trace the deletion flow and identify any places
  where PII persists after deletion."
- "What data retention policies are implemented in code? Are there
  automated expiration or purge mechanisms?"
- "Identify all external APIs or third-party services that receive PII.
  For each, describe what data is shared and whether data processing
  agreements would be required."

STEP 5: SECURITY POSTURE
Use send_message to ask:
- "Identify all hardcoded secrets — API keys, passwords, tokens,
  connection strings. Provide file paths."
- "How are secrets managed in production? Is there a secrets manager
  (Vault, AWS Secrets Manager, etc.) or are environment variables used?"
- "What input validation and sanitization patterns are used?
  Identify any endpoints that accept user input without validation."

STEP 6: SYNTHESIZE
- Generate a "PII & Security Compliance Report" covering:
  1. PII inventory — what data, where stored, encryption status
  2. Data flow map — collection through deletion lifecycle
  3. Compliance gaps — unencrypted PII, missing deletion flows,
     third-party data sharing without controls
  4. Security findings — hardcoded secrets, missing validation,
     auth vulnerabilities
  5. Remediation priorities with estimated effort
  6. Regulatory risk assessment (GDPR, CCPA applicability)

Query 1: "Map the system architecture — services, databases, and external integrations."
Query 2: "For each external integration you identified, what data is exchanged
          and what happens if the external service is unavailable?"
Query 3: "Which of these external dependencies have SLA requirements,
          and are those SLAs enforced in code (circuit breakers, timeouts, retries)?"