ecs: a system that writes a resource should not require ordering every reader by hand #243

Summary

A system can write a resource only by naming it, and once it writes it, it conflicts with every system that reads it, so each reader needs before/after. Adding a reader fails the build until someone remembers the ordering, and the ordering is only ever "the writer first".

Case (mecs, @adobe/ecs 0.2.4)

applyHistory (undo/redo) writes resources[volumeSize]. Ten systems read volumeSize (the face pointing, the controls, a dialog, hover pick, the view's framing...). The build says:

Systems "selectFace" and "applyHistory" both access "volumeSize" and one writes it; order them with before or after.

We fixed it by giving a phase (facePointed, after: [applyHistory]) and adding after: [applyHistory] to the others.

Since #232, the same ordering also decides sync points: every after on a system whose predecessor issues commands adds a sync point (see #245). So an ordering we need only to settle a read/write conflict also changes the schedule's cost.

Requested

Either of:

1. A declared writer role: System.create({ resources: { writes: [volumeSize] }, first: true }), meaning every other accessor of the key runs after, without being edited.
2. Scheduler default: when exactly one system writes a resource and others only read, order readers after the writer, and report an error only for two writers or a cycle.

Notes

Reader/writer order for a resource that one system owns is almost always "writer first"; the explicit form is for the rare reader that must see the old value.