# TUBCO Maintenance Policy

Use this document whenever we maintain the TUBCO customer line.

This is the rulebook for TUBCO. It is intentionally stricter than normal product work.

## Goal

TUBCO stays on its own older customer baseline.

That means:
- keep the older TUBCO application behavior
- keep the older TUBCO database schema
- only cherry-pick approved fixes
- do not quietly turn TUBCO into the newer product

## Source of truth

TUBCO delivery happens from:
- `release/tubco-v1`

Normal product work happens on:
- `develop`
- `main`

Do not deploy TUBCO from:
- `develop`
- `main`

## Core maintenance rules

For TUBCO, we may backport only:
- bug fixes
- security fixes
- carefully approved UX improvements
- required operational fixes for the customer environment

For TUBCO, we do not backport by default:
- new product workflows
- new approval/account-rule systems
- schema expansions from the newer product
- general feature growth unless explicitly approved

## Database rule

TUBCO must use the old TUBCO schema.

This is the most important rule.

If the code stays old but the database is newer, old TUBCO flows can fail with database errors such as:
- missing values for newer non-null columns
- forms saving rows that the old code does not know how to populate

If we see errors like:
- `null value in column ... violates not-null constraint`

then first verify whether the TUBCO environment is still using the old schema.

Do not solve this by default with:
- broad schema compatibility backports
- importing the newer product data model into TUBCO

That would move TUBCO toward the new product instead of preserving the customer baseline.

## LAN server rule

TUBCO is hosted on our local LAN server.

Before deploying any TUBCO fix, verify:
- the server is running `release/tubco-v1`
- the environment points to the intended old TUBCO database
- no newer product migrations were applied there by mistake

If the LAN server is connected to a newer migrated database, code-only fixes may not be enough.

In that case, the correct options are:
1. repoint TUBCO to the old TUBCO database
2. or restore the database to the old TUBCO schema

## Safe TUBCO release workflow

1. start from:
   - `release/tubco-v1`
2. implement only the approved fix
3. keep the database model old unless there is explicit customer approval to change it
4. test the affected flow
5. deploy only to the LAN-hosted TUBCO environment
6. do not run newer product migrations on that environment

## Cherry-pick rule

When a fix exists on another branch:
- inspect the commit carefully
- cherry-pick only if it does not pull in newer product behavior or newer schema assumptions

If a fix depends on the newer schema:
- stop
- rework it as a TUBCO-only fix
- or do not ship it

## Operational checklist before deploying a TUBCO fix

Check all of these:
- branch is `release/tubco-v1`
- worktree is clean
- fix is limited to the approved TUBCO scope
- no new-product migrations are included
- no new-product workflows are included
- LAN server target is the intended TUBCO environment
- database is the old TUBCO schema

## Example warning signs

Pause and verify immediately if you see:
- approval-related fields appearing in old TUBCO flows
- new account-rule behavior on TUBCO
- migration files copied from the product branch
- database errors mentioning columns unknown to the old branch

Those usually indicate code/schema drift.

## Decision rule

If there is a conflict between:
- shipping a quick fix
- and keeping TUBCO on the old customer baseline

choose the old customer baseline first.

We only widen the TUBCO schema or behavior if that change is explicitly intended for TUBCO.

## Related documents

- [TUBCO_SETUP.md](/Users/bostame/Documents/workdock-platform/TUBCO_SETUP.md)
- [DEPLOYMENT.md](/Users/bostame/Documents/workdock-platform/DEPLOYMENT.md)
- [CONTRIBUTING.md](/Users/bostame/Documents/workdock-platform/CONTRIBUTING.md)