Support foundation field as a condition and variable

Objective

• Expose property foundation as a usable merge variable in worklists, emails and related templating (same class of variables as other property fields).

Background

• SE request: teams reference foundation type in client communications.
• Property data already includes foundation on inspections (attik-backend/src/models/inspectionSchema.ts / property subdocument, src/util/functions/inspection/createInspection.ts, Spectora sync filling property.foundation).
• Reports Hub / exports already map property.foundation in attik-backend/src/config/exportFieldDefinitions.ts—email variable catalogs may still omit it.
• In the Monday kickoff, the team clarified that this request sits next to a separate dispatch need: foundation type is also being used operationally to avoid assigning inspectors to crawlspace jobs they cannot perform. This issue should stay focused on merge-variable support for communications and templating, while staying related to the dispatch / permissions work.

Related: ATT-379 covers using foundation type in dispatch logic and inspector permissions.

Scope

Backend (attik-backend)

• src/util/functions/emailBuilder/renderEmail.ts (and any variable registry or helper that lists allowed keys)—add foundation resolution for templates.
• Worklist filtering: worklist conditions that target property attributes are translated to Mongo paths in src/routes/worklist.ts (buildMongoCondition → inner getFieldPath). Today property fields like street, sqft, yearBuilt, etc. map to property.*; foundation must be added there (e.g. map attribute foundation → property.foundation) so worklist rules can filter on foundation the same way as other property fields.
• Schema reference: foundation lives on the property subdocument (attik-backend/src/models/propertySchema.ts); keep types/populated payloads consistent when resolving conditions.

Frontend (attik-frontend)

• Email builder / variable picker UI—surface “foundation” next to other property fields so authors can insert it.
• Worklist builder: src/app/tools/work/NewWorklistDrawer.tsx uses the shared <Conditions> component with property in availableGroups; new property keys must be added to the shared templating catalogs below so they appear in the condition builder (not only in email).

Implementation paths (keep catalogs in sync)

These files define which keys exist for property merge variables and condition attributes; frontend and backend lists should match other property rows (e.g. sqft, yearBuilt).

| Area | Path | | -- | -- | | Shared template keys (frontend — email builder, previews, condition UI) | attik-frontend/src/components/conditions/templatingData.ts → propertyTemplateKeys | | Shared template keys (backend — templateVariableMap / send pipeline) | attik-backend/src/util/functions/emailBuilder/backendTemplatingData.ts → propertyTemplateKeys inside templateKeys | | Backend variable resolution | attik-backend/src/util/functions/emailBuilder/variableUtils.ts → resolveVariableBackend (property category resolves via inspection.property[key] for direct-access keys) | | Frontend variable preview / replacement | attik-frontend/src/app/tools/action-flow/[flow_id]/utils/templateVariables.ts (imports templateKeys from components/conditions/templatingData) | | Worklist condition → Mongo | attik-backend/src/routes/worklist.ts → getFieldPath in buildMongoCondition | | Email send | attik-backend/src/util/functions/emailBuilder/renderEmail.ts |

Optional UI parity: If product wants foundation in the activity-feed “insert variable” menu for notes, update hardcoded key lists in attik-frontend/src/components/activityFeed/JobContextVariableInsertDropdown.tsx (INSPECTION_INSERT_KEYS / QUOTE_INSERT_KEYS).

Tests: Consider extending attik-frontend/tests/util/templateVariables.test.ts (existing coverage for property keys like sqft, yearBuilt) with a foundation case.

Naming note: modifier-foundation elsewhere in templatingData.ts relates to pricing modifier condition attributes, not the same surface as a foundation property merge/condition key—avoid conflating the two when wiring this ticket.

References

• attik-backend/src/config/exportFieldDefinitions.ts (property.foundation)
• attik-backend/src/util/functions/emailBuilder/renderEmail.ts
• attik-backend/src/models/propertySchema.ts (foundation field)
• attik-backend/src/routes/worklist.ts (worklist condition field mapping)