Template-Derived Date — Stale Recompute (Liquid / Computed Fields)

What This Skill Debugs

A date field derived from other questionnaire inputs (e.g. sd_expiration_date from sd_effective_date + sd_term_length) behaves correctly on initial evaluation but stays wrong or stale after the customer or legal team changes an upstream field.

Primary mechanisms (often combinable):

1. Stale value when the main {% if %} guard fails after an edit
   If the derived field is only assigned inside a conditional and there is no {% else %} that clears it, a later edit can leave the previous assign in blanks — Liquid does not implicitly delete keys when the block is skipped.

2. Self-referencing consecutive assigns
   Patterns like {% assign sd_expiration_date = sd_effective_date | plus: sd_term_length %} immediately followed by {% assign sd_expiration_date = sd_expiration_date | minus: one_day %} can interact badly with evaluation order / intermediate blanks in some paths; using a temporary variable for the first result, then assigning the final slug once, avoids read-after-write ambiguity.

3. Typo in | date: format string
   Example from production triage: "%Y-%m -%d" (space before -%d) produced strings like 2025-03 -26 instead of 2025-03-26, breaking string comparisons to "now" | date: \"%Y-%m-%d\"** (e.g. sd_dummy-style gates).

4. Missing explicit dependencies (product recommendation)
   Relying only on raw Liquid assign in template computation without treating the field as a computed field wired to dependencies (sd_effective_date, sd_term_length, etc.) makes it easier to hit partial-update paths where the template author expected a full re-eval that does not match runtime behavior. Preferred fix class: model the derived date as a computed field with formula effective_date + term_length - 1 day (or equivalent) so dependency changes trigger recomputation explicitly.