Feeding delivery

A keeper delivers the pending feeding for a paddock. The delivered feeding records who signed for it; a planned feeding has no signer. Four modules and a system file define the workflow.

What the interface says

Read park/feeding.brass without its bodies:

In park/control.brass, deliver_feeding holds one access, registry, for paddocks 1 to 5. It tests that who is a Deliverer, then calls a private helper to read, deliver and save the feeding.

Its after promises that the result is for the requested paddock and signed by who.

Adding delivered_by connects the state declaration to the caller:

plan is untouched because a Planned feeding must not mention the field. The trials behind this design are described in principles §4.

What breaks if it changes.

Which promises are checked, and where?

Proven

Enforced

Assumed

The optional impact_modules policy reports changes that exceed the configured scope. It is separate from the promise tiers and does not reject a program. Its count is provisional (spec §10.1).

The wrong edit, rejected

A model simplifies signer:

# park/feeding.brass — wrong edit
  fn signer(f) = Ok(f.delivered_by)
fault field not present on this path: delivered_by needs status in {FeedingStatus.Delivered}
  at park/feeding.brass: fn signer
  in scope: f: Feeding (not narrowed)
  fix: test f is DeliveredFeeding first, or take a DeliveredFeeding

Writing delivered_by into a Planned literal is also rejected. The field exists only in the Delivered state.

What these declarations leave open