Source lineage and boundaries

Barrow was generated and composed from committed Base fc0e1041efa55771142bbb57c4ab4743147e264d, then converted to package mode. It now pins exact @runeditrun/rer 0.2.22. composition.lock.json records the original source copies. Base's operator auth, development mail, first-run flow, theme, portability and D1 import-kit are reused. Current runtime copy pins are listed below; applied SQL retains its original revision. Application changes live under src/barrow; no sibling source repository is modified.

• Pier orders, catalogue and native reservations: src/barrow/pier.ts adapts Pier's decimal string conversion and consumes its real state and idempotent order command. Reservation logic stays in Pier. Native reservation import remains a Pier migration operation, not a checkout shortcut.
• Orbit account repository: account associations are explicit stable IDs and verified email identities, adapted to one trade buyer email per account. Barrow stores the exact Pier party ID, never a fuzzy company-name match.
• Nectar receivables: the invoice handoff follows integer-cent commercial values and separates issue/due dates from payment. It does not record payments or duplicate Nectar's receivables ledger.

The initial stock adapter requires a current Pier operator session because that release has no dedicated service credential. Expiry is an explicit connection failure. Only the server sees it; customer catalogue responses contain permitted SKU data and prices. Stock displayed before approval is an observation, not an allocation. A stable request identity recovers uncertain Pier outcomes, and invoices require every line reserved.

The published RER package supplies the command lifecycle and static run-site build and deployment. No local RER patches are applied. The run site renders the Markdown in this docs/ directory at build time; guides are maintained here alongside the code.

Demo adoption refreshes every vendored runtime module together from Base 1ce15dd8cbb7c8cf2d83ebfde2b4a8a130ff9d74 (rer-v0.2.22); Base record-base records the selected bytes in base-copies.json. Applied SQL keeps its historical provenance; the additive owner-signin migration is recorded at the new pin. The original runtime entries have moved out of composition.lock.json into this supported current-copy record. See Demo.