|
4 | 4 |
|
5 | 5 | - Make code changes on `mv2` first. |
6 | 6 | - `main` is the real MV3 branch. |
7 | | -- `mv3` is retired. Do not use it as the normal MV3 source branch for new work or cross-repo sync. |
| 7 | +- `mv3` and `mv3-ltl` are retired. Do not use them as MV3 source branches for new work or cross-repo sync; `main` is the MV3 line LiveTL consumes. |
8 | 8 | - Do not implement feature/fix work directly on `main`. |
9 | 9 | - If a task starts on another branch, switch to `mv2` before editing unless the user explicitly asks otherwise. |
10 | 10 | - If a task touches both HyperChat and LiveTL, HyperChat still goes first. |
11 | 11 | - Cross-repo order is mandatory: |
12 | 12 | 1. HyperChat `mv2` |
13 | 13 | 2. HyperChat `main` |
14 | | - 3. HyperChat `mv3-ltl` |
15 | | - 4. LiveTL `develop` |
16 | | - 5. LiveTL `mv3-fr` |
17 | | - 6. LiveTL `release` |
| 14 | + 3. LiveTL `develop` |
| 15 | + 4. LiveTL `mv3-fr` |
| 16 | + 5. LiveTL `release` |
18 | 17 | - Never start cross-repo work in LiveTL when the HyperChat submodule also needs to change. |
19 | 18 | - If the task also requires syncing YtcFilter (YTCF), do it after HyperChat `main` is updated: |
20 | 19 | - merge HyperChat `main` into YTCF `master` |
|
29 | 28 | - `order matters` |
30 | 29 | - Avoid padded scopes, issue-number prefixes, and changelog-style essays in commit subjects. |
31 | 30 | - A slightly dry or funny commit is fine if it is still clear at a glance. |
32 | | -- Prefer proper merges when carrying `mv2` work into `main` and `mv3-ltl`. |
33 | | -- Carry `main` into `mv3-ltl`. Do not treat `mv3` as the normal hop between them. |
| 31 | +- Prefer proper merges when carrying `mv2` work into `main`. |
34 | 32 | - If MV3 needs follow-up adaptation, keep that as a small, explicit commit after the merge instead of rewriting history or hand-copying changes. |
35 | 33 |
|
36 | 34 | ## Code Patterns |
37 | 35 |
|
38 | 36 | - Prefer editing existing modules and utilities over creating one-off files for tiny helpers. |
39 | 37 | - If a helper obviously belongs in an existing shared utility file, put it there. |
40 | | -- Put shared behavior on `mv2` first; `main` and `mv3-ltl` should usually be merge-plus-adaptation branches, not separate feature branches. |
41 | | -- Keep `mv3-ltl` branching from the current `main` line once `main` has the intended HC changes. |
| 38 | +- Put shared behavior on `mv2` first; `main` should usually be a merge-plus-adaptation branch, not a separate feature branch. |
42 | 39 | - Keep MV3 adaptation narrow: |
43 | 40 | - preserve branch-specific build/runtime wiring |
44 | 41 | - change only what is required for manifest/background/injection differences |
|
0 commit comments