Transfer and handover

Checklists for handing Rampline to someone else. Three cases are different and need different steps:

Case	What changes hands	Licensing keys
Licensee installs a copy (self-hosted, agency reseller, source-code license)	A release package and a license	The licensor keeps the signing key; the licensee gets a signed license
White-label operator on your cloud	An operator account on your installation	Nothing to hand over; licenses optional
Sale of the software as an asset	Code, rights, infrastructure, domains, accounts, customers	The private signing key moves to the buyer, or the buyer creates a new key pair (section 4)

The software records rights and limits in signed licenses. The legal terms belong in written agreements; draft outlines for a lawyer are in docs/legal/.

1. What a buyer or licensee receives

The release package rampline-<version>.tar.gz and its .sha256 file, made with npm run release:pack from a clean, committed state. The script refuses to pack while files are uncommitted, and refuses if .env files or signing keys were ever committed.
For a licensee: the license text (RL1.…) and the signed agreement.
For an asset buyer: the full Git repository with history (git bundle create rampline.bundle --all), not only the release package.
Documentation: README.md, docs/INSTALL.md, docs/OPERATIONS.md, docs/LICENSING.md, docs/DEPENDENCIES.md, docs/IMPLEMENTATION_STATUS.md (what is done and what is not), docs/03-ARCHITECTURE.md.

2. Handover checklist (every case)

[ ] Release package built with npm run release:pack, checksum sent separately from the package
[ ] The recipient installed it from the package alone, following docs/INSTALL.md, on their own server and accounts
[ ] npm run install:check -- --fresh passes on their database server (clean installation into a throwaway database)
[ ] npm run install:check -- --smoke passes on their running installation
[ ] License activated and shown as valid under Platform, Licenses (independent edition)
[ ] Their own email provider, Stripe test keys and (optionally) Anthropic key connected, a test checkout paid
[ ] Backups scheduled and one restore tested (docs/OPERATIONS.md)
[ ] docs/IMPLEMENTATION_STATUS.md read together: what is built, what is partial, what is not started
[ ] docs/DEPENDENCIES.md reviewed, including the items listed under "For review"
[ ] Support period, contact and response times agreed in writing [NEED: terms]

3. Asset ownership checklist (sale of the software)

[ ] Source code: full repository with history, all branches and tags
[ ] Copyright: confirmation that all code was written by the seller or under licenses listed in docs/DEPENDENCIES.md [NEED: seller's confirmation, contributor agreements if anyone else contributed]
[ ] Product name and logo: trademark search done and rights transferred where they exist [NEED: trademark search; "Rampline" is a working title]
[ ] Design assets and copy written for the product
[ ] License signing key (section 4)
[ ] Register of issued licenses: Platform, Licenses on the seller's installation, exported as part of the database
[ ] Customer contracts, open invoices and subscriptions that move with the asset [NEED: list]
[ ] Third-party accounts listed in section 5, moved or recreated by the buyer
[ ] Open obligations: support promised to licensees, refunds, warranties [NEED: list]

4. The license signing key

Licenses are verified with the public key in license/public.pem, which ships in every copy. The matching private key (.license-keys/private.pem or LICENSE_PRIVATE_KEY) exists only on the licensor's server.

Licensees never receive the private key.
An asset buyer has two options:
- Take over the existing key pair: the seller hands over the private key through a secure channel (in person or an encrypted password-manager share) and deletes every copy afterwards. Licenses already issued stay valid.
- Create a new key pair (npm run license:keygen), commit the new license/public.pem and issue new licenses to existing licensees, who update to a release with the new public key. Old licenses stop verifying on updated installations.
Revocation lists (/api/license/revocations) are signed with the same key. If the buyer runs the licensing server under a new address, licensees who use LICENSE_REVOCATION_URL update that variable.

5. Domain and infrastructure checklist

List each item with its current owner and how it moves. Recreate rather than share credentials: the buyer creates their own account, the seller transfers the resource or the data, then closes theirs.

Item	Typical move
Product domains (marketing site, app, licensing)	Registrar transfer or account change; lower DNS TTLs a day before
DNS zone	Export the records, recreate at the buyer's DNS host, then switch name servers
Server or hosting account	Fresh install at the buyer (docs/INSTALL.md), restore of a backup (docs/OPERATIONS.md, section 2)
Database and uploaded files	Backup and restore, or workspace exports for individual customers
Object storage bucket	Copy objects to the buyer's bucket, then change `S3_*`
Email provider and sending domain	Buyer creates an account, verifies the domain (SPF, DKIM), sets the variables
Stripe	Each workspace has its own Stripe account; nothing central to move. Platform invoices are collected outside the software
Anthropic or other API keys	Buyer creates their own keys; the seller revokes theirs
Source hosting (GitHub or similar)	Repository transfer or push of the bundle to the buyer's organization
Monitoring, uptime checks, backups off site	Recreate under the buyer's accounts
`SECRET_KEY` and database passwords	Move with the installation if the database moves; otherwise new values on the new installation
Marketing accounts, social profiles, mailing lists	[NEED: list, and consent basis for moving subscriber lists]

6. After handover

[ ] Seller's access to servers, databases, buckets and third-party accounts removed
[ ] Seller's platform administrator account removed from the buyer's installation (Platform admins are rows in platform_admins)
[ ] Secrets the seller knew are rotated: SECRET_KEY only if credentials can be re-entered, database passwords (new APP_DB_PASSWORD and SERVICE_DB_PASSWORD in .env, then docker compose restart app worker; the superuser with docker compose exec db psql -U postgres -c "alter role postgres password '<new>'" and the same value in POSTGRES_PASSWORD), provider keys
[ ] Final release and repository state tagged and archived by both sides