Keep public and project-specific changes identifiable
The public repository provides reusable engineering code with a root MIT LICENSE and separate third-party notices. The private official project develops website and operating features from an identified public commit. Those additions are not automatically published upstream.
Customer service rules, internal integrations, and dedicated configuration belong in the agreed customer project. Reusable defects can be addressed in a separate public checkout. Restrict public-remote pushes from workspaces containing private changes so a routine push cannot publish unauthorized code.
Record the upstream commit, project patch, and build dependencies for a derived release. An archive without provenance makes it difficult for the next team to distinguish framework files from modifications it must preserve. The public repository provides the engineering reference.
Check licenses and other assets individually
Source deliveries should retain the license and copyright notices that apply to them. The root LICENSE cannot establish the provenance of every font, image, SDK, or component. Third-party notices record these materials separately.
Before customer delivery, redistribution, or agreeing the use of proprietary changes, review the relevant files and project agreement. Licensing conclusions belong with the rights holders and qualified legal advisers. No substitute sublicense or contract terms are supplied here.
Manage credentials in the runtime environment
Database passwords, email-provider credentials, OAuth secrets, and signing private keys must stay out of source archives. A private Git repository is also unsuitable as a secret store. Development documentation can describe configuration names, acquisition steps, purposes, and permissions while controlled environments supply production values.
An OAuth handover should identify callback-domain ownership, provider-account administrators, and rotation steps. It must be possible to revoke a departing maintainer's access and identify which services need reloading after a secret changes. Otherwise a delivered codebase can remain dependent on a former developer's personal account.
Make delivery scope testable
For a service app, specify who may assign work, which states permit reassignment, how offline reports are submitted, and who supplies the equipment register. “App, admin, and push” leaves those acceptance decisions unresolved.
| Handover material | Information to retain |
|---|---|
| Source and build | Commit, dependency locks, commands, and required tool versions |
| Database | Migration version, existing-data treatment, verification owner, and recovery procedure |
| Runtime environment | Ownership and access for domains, cloud resources, certificates, and provider accounts |
| Test record | Scenarios, devices, system versions, actual results, and unverified prerequisites |
| Maintenance agreement | Defect handling, compatibility updates, deployment approval, and replacement-team handover |
Push needs particularly precise evidence. Server acceptance, vendor acceptance, and a displayed device notification are different observations. Record them separately. Keep physical-device acceptance pending when no real device has taken part.
Accept upgrades in the derived project
Compare the public baseline with local modifications, inspect database changes, and schedule conflict resolution, builds, and business regression tests. Retain the old release, configuration, and a restorable backup so the agreed recovery procedure is available. A successful merge establishes only that source conflicts have been resolved.
The website's free catalog supplies module source with provenance and license information. It includes no purchase order, paid entitlement, or response-time commitment. Projects requiring implementation services should separately agree scope, fees, maintenance, and acceptance against the service documents actually published.
Source documents: LICENSE and third-party notices. For module adoption, see the free source catalog explanation.