chore: the local develop branch is an orphan of the previous project line #35

The repository has two branches with completely DISJOINT histories:

$ git merge-base main origin/develop
(no output, exit 1)
$ git rev-list --count origin/main
4
$ git rev-list --count origin/develop
56

main holds 4 commits and is the current line of work: the M0 scaffold (eeef32c), the M1 core skeleton (150e7f5) and the merges. origin/develop holds 56 commits from an earlier project line (marketing site, core engine, ADRs up to 0023) and shares no commit with main.

Every recent pull request has been merged into main: #24, #25, #26, #28, #30, #32. The CI workflow triggers on pushes to main.

Consequence for the git-flow rules

The workstation guide says main must stay a subset of develop, and that a back-merge PR should be proposed when git rev-list --count develop..origin/main is non-zero. Here that count is 4, but the histories are disjoint, so a back-merge would graft two unrelated trees together rather than reconcile anything. The back-merge rule does not apply to this repository in its current shape.

The tooling change in #33 therefore branches from main and targets main, because that is where the red CI lives and where the rest of the project is developed.

Decision needed from the owner

• Retire develop. Delete the remote branch, or reset it to main, and drop the back-merge rule for this repository. The git-flow table then needs a single-branch variant.
• Or keep it as an archive and state in the workstation guide that the back-merge rule does not apply while the histories are disjoint.

Until this is settled, agent-created branches should target main, because a pull request into develop would land in a tree that shares no history with the current work.

No action is taken here: agents must not delete branches or open back-merge pull requests.