Files
alla-allaos-fullstack/docs/implementation/task-d51-lead-foundation-stabilization.md
phaichayon b42a4c0777 task-d.5.1
2026-06-24 13:00:43 +07:00

5.2 KiB

Task D.5.1: Lead Foundation Stabilization & Output Completion

Objective

Audit the existing D.5 phase-1 lead foundation work, avoid duplicate schema creation, complete missing registration outputs, and confirm current CRM compatibility before D.5.2 lead API work begins.

Review Completed

  • AGENTS.md
  • docs/standards/project-foundations.md
  • docs/standards/task-catalog.md
  • docs/adr/0018-lead-enquiry-domain-separation.md
  • docs/implementation/task-d5-lead-enquiry-domain-separation.md
  • src/db/schema.ts
  • src/db/seeds/foundation.seed.ts
  • drizzle/0020_lead_foundation_schema.sql
  • drizzle/0021_worried_nebula.sql
  • drizzle/meta/_journal.json
  • src/features/foundation/master-options/types.ts
  • src/features/foundation/document-sequence/service.ts

Existing Foundation

Verified present in the repository:

Missing Foundation Found

The missing outputs were not schema objects. They were governance and contract gaps:

  • no dedicated Lead Foundation entry in project-foundations.md
  • no Task D.5 or Task D.5.1 registration in task-catalog.md
  • master-option category type registry did not include the new lead option categories, which made the seed data harder to discover and reuse from foundation settings code
  • no D.5.1 implementation summary existed

Partial / Compatibility Findings

Migration history duplication risk

Lead schema work appears twice in migration history:

Compatibility status:

  • 0020 is idempotent with IF NOT EXISTS
  • 0021 is a later non-idempotent generated migration for the same structural slice
  • D.5.1 did not create any additional migration, in line with task rules

This is recorded as a migration-history cleanup risk for future maintenance, not changed by this task.

Sequence compatibility

The foundation now includes both legacy and future-facing enquiry sequence types:

  • legacy active enquiry service still generates documentType = enquiry
  • lead split foundation seed also registers crm_enquiry

That means the seed layer is ready for split-domain work, but production enquiry creation is still compatible with the older enquiry document-type contract until D.5.2+ refactors the service layer.

Active production model

Current CRM production behavior is still primarily driven by the old shared enquiry foundation:

  • lead and enquiry workspace separation still relies on crm_enquiries.pipeline_stage
  • no lead API, lead UI, or lead assignment flow exists yet
  • dashboard and reports still rely on the pre-split data model

This is expected and remains in scope for later D.5 phases.

Changes Completed In D.5.1

  • added Lead Foundation registration to docs/standards/project-foundations.md
  • added Task D.5 and Task D.5.1 to docs/standards/task-catalog.md
  • extended CRM_MASTER_OPTION_CATEGORIES to include the new lead option categories in src/features/foundation/master-options/types.ts
  • added this implementation note

No Duplicate Creation Performed

D.5.1 intentionally did not:

  • recreate crm_leads
  • recreate crm_enquiries.lead_id
  • generate a new migration
  • rename existing schema objects
  • create lead APIs or UI

Compatibility Verification

Verification executed:

  • npm exec tsc --noEmit

Result:

  • current Customer, Contact, Enquiry, Quotation, Dashboard, and Reports code continues to typecheck after the D.5.1 stabilization changes

Output Summary

Existing Foundation

  • crm_leads
  • crm_enquiries.lead_id
  • ADR-0018

Missing Foundation

  • Lead Foundation registry entry
  • Task catalog registration for D.5 and D.5.1
  • master-option category contract coverage for lead option seeds
  • D.5.1 implementation summary

Completed Foundation

  • Lead schema and seed presence verified
  • lead option categories registered in foundation type contracts
  • Lead Foundation registered in the standards registry
  • Task D.5 and D.5.1 registered in task history
  • compatibility state documented for D.5.2 planning

Ready For Next Task

The repo is now better prepared for Task D.5.2 Lead API Foundation because:

  • the foundation state is discoverable
  • duplicate schema creation was avoided
  • lead option categories are registered in the shared master-option contract
  • current compatibility boundaries are explicitly documented