Pier operations
Pier is a package-mode seed. package.json pins the published @runeditrun/rer 0.2.0 package; the app adapter in scripts/installer/local.mjs selects the shared installer, local development and preview targets, verification command, owner deployment target and local portability adapter. The operation names and required deployment inputs are declared in OPERATIONS.json. The source graph records Base 4c83ea57efc3a5b462426c6abc88826b72375112 separately from the CLI package version. There is no checkout-local copy of the RER CLI.
Local start
Use the shared installer, then the bare project verbs:
npx -y @runeditrun/rer cli install
rer install
rer setup
rer dev
The alternate installer is curl -fsSL https://runeditrun.com/install.sh | sh. rer install installs the pinned dependency set. rer setup prepares the local application and declared D1 migrations. rer dev serves the actual local Worker and persistent D1 with Base's native development identity; open its local URL on this computer and finish the owner claim at /setup. The shared Base Lobby owns /, and Pier opens at /app. Keep the printed local open URL private. Stop the server with rer dev --stop.
Node 22.20.0 and pnpm 10.12.4 are pinned. Local setup does not require Cloudflare credentials, an external identity issuer, an email provider, an embedded model or a supplier account. No business fixture is created for the operator. For ordinary local sign-in, run rer outbox: it prints the development outbox address on this computer, where one-use links requested at /signin arrive, and rer outbox --owner-email EMAIL requests the owner's link. It does not send external email.
Commands and their boundaries
rer buildproduces the production Worker and assets with local development identity excluded.rer verifyinvokes the adapter's declared local verification hook. That hook runs typecheck, the production build, the focused Worker/D1 API suite, email-link checks andtests/portable.mjsfresh-install archive restore. It is a local verification command; its result must be reported from an actual run.rer checkinspects this checkout's declared operation contract and source selections.rer describereports supported commands, flags and effects. Use both before relying on a command's state effects.rer export --output exports/pier.rerandrer import --input exports/pier.rer --yeshandle the complete installation archive. This archive is distinct from Pier's native CSV import workflow documented in IMPORT.md.- Native CSV import accepts the six established kinds and optional
reservations.csv. Include that file to retain exact reviewed open-order allocations by bin and explicit zero backorders; omit it to use the six-kind import's normal hard-reservation allocation. rer reset --yesremoves the declared local installation state and is destructive. Export first if the data matters.rer deploytargets the owner's configured Cloudflare account using the declareddeploy.jsonand theCLOUDFLARE_ACCOUNT_IDandCLOUDFLARE_API_TOKENinputs. No deployment was run and no hosted deployment is accepted in this round. Local success does not establish hosted health or provider behavior.
All public commands use bare rer verbs. rer export/rer import are the installation portability commands; native stock migration is reviewed inside Pier using the CSV contract. No accounting, payments, supplier send, carrier or model integration is enabled by this seed.
Backup and restore
Stop local serving before backup, reset or restore so no command can write during transfer. The installation archive is intended to preserve business records and their stock, reservation, approval, command and import-custody evidence. Durable operator, role and approval identities remain audit evidence, never access grants. Native credentials, sessions, tokens, local outbox and private settings are excluded; establish a fresh native session for the retained owner before operating. The fresh-install restore and new-transaction journey is locally proven by tests/portable.mjs, as recorded in ACCEPTANCE.md.
For a same-checkout local restore:
rer dev --stop
rer export --output exports/pier.rer
rer reset --yes
rer import --input exports/pier.rer --yes
rer setup
rer dev
An archive restores with the Pier release that made it: record the commit (git rev-parse HEAD) beside each archive and restore into a checkout of that commit. For another empty checkout of that release, run rer install, restore with rer import --input exports/pier.rer --yes, then run rer setup and rer dev. Sign in with a fresh native session for the retained owner identity. Review balances, reservations, remaining order and PO quantities, audit links and retained source files before resuming use. A business export or CSV preview alone is not proof of a complete installation restore.
Stock authority and incident handling
The edition roles are owner, buyer, operator, warehouse, viewer and agent. Native sessions establish the actor; the current edition role controls stock and document commands. After signing in with an existing native session, an owner opens Pier at /app → Activity → Invite an operator, then assigns a Pier role with Pier's existing operator-role form. A new invitation starts as viewer; invitation status is visible in the interface. Base's accepted response confirms the invitation request, not delivery. Local delivery uses the native development outbox; no live email provider is configured. Buyers approve exact purchase commitments; operators approve reservation reallocation; warehouse staff perform and approve physical count/receipt/dispatch work; viewers read; agents prepare proposals. The owner decides source reconciliation. Changing a role or revoking native access must affect the next write.
Trace a position through its append-only movements, source document, actor, reason, command identity and any correction/import link. Retry a response-loss case with the same command identity and same payload. Do not repair a balance by editing a generic record or database row. Receipt reversal, count correction, return restocking and import undo must review downstream dependencies and use linked compensating operations. Already dispatched goods require a real return; restoring a snapshot cannot make them physically available.
The complete operational flows, local proof and remaining boundaries are recorded in CONTRACT.md and ACCEPTANCE.md. This documentation does not claim acceptance of hosted operation, provider integrations, owner export completeness or physical warehouse accuracy.