# What to review before using this light package

The linked package is the real model output, preserved as an unapproved draft. These are editorial review notes; they are not extra provider findings or implemented changes.

These observations concern the recorded 2026-10-01 example. On a new reproduction, check each observation against the new output before using it. The companion archive adds this note as `COOKBOOK-REVIEW.md`; it does not alter the seven generated package files or approve the specification.

1. **Keep the build sequential.** The brief requested two sequential waves and one builder. The draft labels its first wave parallel while its concurrency section permits only one builder. Resolve that conflict before handing it to a builder.
2. **Separate acknowledgement from ownership.** The answer uses “acknowledges (claims)”. Acknowledging that a handover was read should not silently reassign the issue owner. Choose the exact behaviour and acceptance check.
3. **Keep the first version small.** The generated third module adds a pilot comparison view and local telemetry. Those additions need review against the six-field log and export scope; they are not established user needs.
4. **Decide how recovery works.** One story expects a JSON export to load back into the app while describing import as optional. Decide whether restore belongs in the prototype, then make the requirement and acceptance check agree. Choose the device, browser and stable application address before testing persistence.
5. **Measure the value of software separately.** The model proposed a two-week paper pilot with at least ten handovers, 90% field completeness, 80% acknowledgement within fifteen minutes and at most 10% ambiguity. These are proposed pilot targets. Meeting them would show that the structured process can work; it would not establish that software improves on paper. Compare both before committing to a build.

Suggested next steering prompt:

> Revise this draft only. Keep one builder and make both waves sequential. Define acknowledgement as recording receipt, without changing the owner. Remove telemetry and the comparison view from the first version. Resolve the optional-import acceptance conflict explicitly. Separate the paper-process gate from a later software-versus-paper comparison. Keep the three original source cards, preserve every unresolved assumption, and do not start a build or a commissioned package run.

This revision prompt is an example for the reader. It was not submitted as another paid call in the recorded run.

Synatrail automatically adds a scoped answer to the canvas. For this example its answer card was removed with the normal graph edit, retaining the full saved conversation and receipt. The final investigation has the original three nodes. The first scope review saw that temporary answer card; the package itself used only the three selected input cards plus the saved answer. The reproducible script now removes the answer card immediately after the answer is saved.