T4: Basic hierarchy

[PrjShrestha]

Importance: Must have · Size: M · Depends on: nothing

Why. The contact hierarchy is the foundation everything else rests on. Without contact types
there is no subject to attach a report to, no surface for a form to appear on, no way to create a
person, and no data replication to a device. It is listed modestly in the design doc but it is a
hard prerequisite.

Scope.

• A guided flow to define hierarchy levels and roles: choose the depth, name each level.
• Write the contact types and the place hierarchy into app settings. ⚠ Touch only those
  keys — every other setting in the file must be left byte-identical.
• Maintain the place-types file alongside it.
• ⚠ Person types must receive their create and edit form references. Without them CHT offers no
  way to add that person, and the omission is invisible until someone looks for the button.
• Edit leaf-level contact details — name, phone, supervisor — through the contact forms.
• ⚠ Make no unrequested semantic changes. Editing a display name must not re-derive the
  hierarchy ordering or backfill properties the author deliberately omitted.

Not in scope. Complex restructuring — splitting a district, adding a level or a region — is
explicitly out of MVP.

Acceptance.

1. Editing one character of a display name produces a diff containing only that change,
   asserted against a real project folder.
2. A three-level hierarchy plus one person type is created through the guided flow, deploys, and the
   "add person" affordance appears in CHT.

---