Coflyr · Common maintenance reporting · DB pending
Common maintenance defect and damage reporting
Model index · WorkStep consolidation
Use the existing shared reporting framework for maintenance defects, damage and non-routine findings. Direct WorkStep-origin intake is added to the backend. Database migration, legacy backfill and closure/release workflow adoption remain pending complete project review.
Standard records
| Model | Responsibility |
|---|---|
| DefectDamageReport | One reported occurrence: origin, affected asset, kind, description, discovery, severity and reporting attribution. |
| DefectDamageDetail | Repeatable Observation, Measurement, Location, Attachment, Source and Action rows. Damage measurements and locations stay within this framework. |
| DefectReferenceValue | Shared typed categories, severity and damage/measurement/location/action classifications. |
| WorkStep | Originating maintenance step and corrective executable steps, with signed actions and inspections. It links the occurrence; it does not store another copy of its defect/damage description. |
Direct maintenance reporting
POST /api/DefectDamageReport/maintenance-occurrences with WorkStepId and the normal report fields/details. IsMaintenanceOccurrence is true. The server checks step/owner visibility and derives the aircraft NRC or component COMP domain and originating workorder. ReportKind is Defect, Damage or DefectAndDamage. The WorkStep origin is immutable and cannot coexist with a duplicate production/component finding/damage source.
The existing generic report API can also create this form with IsMaintenanceOccurrence=true. Report-number allocation, audit, draft state, reference catalogue validation, repeatable details and affected-asset fields remain shared. Maintenance occurrences use the report header WorkStepId as their source; they do not need a Source detail representing a separately created legacy finding.
Maintenance example
An engineer finds a cracked pump housing during a component inspection step. Create one COMP report with ReportKind=Damage, the affected component and the inspection WorkStepId. Add location, crack measurement and photo details. A corrective WorkStep performs the approved repair and its signed action/inspection supplies rectification evidence. The same framework handles an aircraft inspection finding using NRC.
Retirement readiness
| Legacy reporting table | Reporting replacement | Remaining adoption work |
|---|---|---|
| ProductionFindings | DefectDamageReport NRC occurrences and details | Port severity evaluation, finding hours, relevant/open status, closure and ProductionExecution acceptance/performance queries. |
| ComponentWorkpackageFindings | DefectDamageReport COMP occurrences and Action details | Reconcile package/event/step ownership, signed rectification and component release-readiness checks. |
| ComponentWorkpackageDamages | DefectDamageReport COMP occurrences with ReportKind=Damage | Preserve damage/node/asset identity, raised provenance and closure state. |
These three tables remain Under development, not Dropped. The shared report currently has intake states Draft/Submitted; those are not repair closure states. A reporting occurrence must not be treated as resolved merely because it is Submitted or its originating step is complete. Existing workflow records/checks remain until their lifecycle is explicitly moved to shared events/requirements, corrective steps and signed evidence.
Migration requirements
- Add the direct-maintenance origin column/check and restrict its WorkStep FK; update the deployed deferred origin trigger to recognize a WorkStep-origin maintenance report without a legacy finding/damage Source row.
- Backfill existing reporting rows and their details, attachments and identifiers, with one occurrence per source; reconcile duplicate legacy/common occurrences and cross-domain references.
- Move closure, release and performance readers/writers together before retiring a legacy table. Do not drop flight-log, audit, deferred, engineering or inventory workflow aggregates merely because they share reporting fields.
Resource and spare ownership
ComponentTaskResourceRequirements and ComponentTaskPartRequirements now have WorkStep as their retirement replacement. New resource demand uses WorkStepResourceRequest; new spares demand uses WorkStepMaterialDemand. MaterialPartRequest manages fulfillment with WorkStepMaterialDemandId. Requirements remains the compliance/obligation framework; legacy component demand scopes are read-only until migration. Reusable planning inputs can use existing repository revision resource/part JSON and are copied into each executable step occurrence.