A feature is not complete merely because one repository compiles. Start with one Wildbase Work task that names every repository and the order in which compatible pieces can land.
The usual Packbase sequence
- Domain and API: define the behaviour, authority, error cases, and server contract.
- Server: add backward-compatible support and tests.
- SDK: expose and validate the contract through the typed client.
- Web hooks: adopt the released SDK and own query state, invalidation, and mutation recovery.
- Interface: render the complete behaviour and its accessibility, copy, and failure states.
- Cleanup: remove temporary compatibility only after all supported callers have moved.
An implementation may develop those steps in parallel. Merge order still needs to leave every deployed combination safe.
Plan compatibility before code
Use a small matrix on the task:
| Component | Before | Transitional compatibility | Final |
|---|---|---|---|
| Server | Existing contract | Accepts old and new callers | New contract only, if removal is justified. |
| SDK | Existing release | Parses both response shapes or exposes additive capability | Published version used by the web. |
| Web | Existing SDK | Feature gated by capability or optional field | New UI and hooks. |
| Data | Existing rows | Backfilled or read compatibly | Constraint tightened only after data is ready. |
If there is no safe mixed-version state, treat the change as a coordinated release with a named release owner, maintenance or rollback plan, and explicit timing. Do not hide the requirement inside a PR description.
Keep the tasks connected
Each pull request links the same parent task and the adjacent pull requests. Record:
- the dependency it requires;
- the version, commit, or schema state it was tested against;
- which part may merge first;
- what must not deploy yet; and
- the cleanup condition.
Do not copy a server response type into the web repository as a permanent shortcut. Do not bypass the SDK with a one-off fetch to avoid publishing its change. Do not leave a server route undocumented because only one current UI uses it.
Use the current Packbase SDK and REST API documentation to establish the supported published contract. Do not infer the current contract from an archived checkout. Package publication remains a separate authorised release step: record the intended version and publish owner, and do not make the consuming web pull request depend on an unpublished local package without an explicit non-deployable development plan.
Admin integration uses the same rule
The old Packbase admin UI is retired. A replacement moderation or staff workflow normally crosses the existing server /admin or product route, the SDK boundary, Packbase web hooks, and a product-native interface. New client work lands in packbase-react-ui; do not revive apps/admin or modify the frozen apps/web tree.
Verify the seam
Run each repository’s focused and full relevant checks. Then verify the integration against the exact compatible versions named on the task. Check authentication, forbidden access, empty and stale data, error translation, cache refresh, and repeated mutation.
If an environment needed for end-to-end verification does not exist, say which seam remains unverified and leave a runnable procedure for the person or future task that can verify it.