No Box can target a base branch that is not the trunk, so run 4 cannot merge to integration/dlc

Question

Run 4 merges to a long-lived integration/dlc branch, by the two-act delivery decided while charting
#498. No Box can target it. What changes so
that it can, and does the rule stay stated three times?

Observed, 2026-09-17 22:55 CEST on develop at fd9739e

Three Boxes each derive the base branch from project.branching, and no config value overrides it.

project.branching accepts gitflow | github-flow only (README.md:172, commands/setup.md:272), and
the Consumer's config says gitflow. Both values resolve to develop or main. There is no third
answer.

git -C ~/Sites/FZAG/DXP-DesignSystem ls-remote --heads origin | grep -i integration returns nothing:
the branch does not exist either.

So act 1 fails at its first step, not its last. /build's open-pr would open the pull request
against develop; /qa would then refuse to merge a pull request whose base is not develop, which is
the fail-closed behaviour working correctly against a target nobody can express.

The review Box is the one that fails quietly. Its :185 computes the review's diff from
expected_base. While integration/dlc has not diverged from develop the merge-base is the same
commit, so the bench reads correctly today and starts reading the wrong diff the moment develop moves.
Nothing reports it.

Why it is its own ticket

It touches unic-dlc-build.yaml, which #439
also edits. #439 is nineteen criteria about a different change, and folding a base-branch key into it
would hide this one inside the largest ticket on the map. The ticket that lands second rebases onto the
first — decide the order when the second is grilled, and say so in its criteria.

Not decided, and the second one is the interesting question

• Whether the fix is a config key or a single source. A key both bootstrap nodes read is the
  obvious answer and it is also a fourth surface stating the same rule. The rule "develop when
  gitflow, else main" is written out three times in three YAML files today; that is the shape this map
  exists to fix, and adding a key without collapsing the three leaves the drift in place. Collapsing them
  is a larger change than run 4 needs. Decide it explicitly rather than by default.
• Whether github-flow should have been the answer all along, with main replaced by a named base.
  The enum encodes a branching model and then uses it to answer a different question: what this run
  targets. Those are the same thing only while every run targets the trunk.
• Who creates integration/dlc, and from which commit. #502
  owns creating it today; if this ticket adds a bootstrap step that creates a missing base, that moves.

Surfaces that change with it

• unic-dlc-build.yaml:47, :800; unic-dlc-qa.yaml:45, :427; unic-dlc-pr-review.yaml:48, :185.
• README.md:172 and commands/setup.md:272 — the config table and Step 6.
• docs/boxes/unic-dlc-build.md:74, which hard-codes "base develop". That line is a claim about
  what the Box does that does not derive from the Box, so it is also a row for
  #499's list, found while measuring this.
• An ADR. The plugin's convention since #452 is
  inline revision with Accepted (YYYY-MM-DD, revised YYYY-MM-DD) and no amendment block
  (apps/claude-code/unic-archon-dlc/docs/adr/README.md:18).

Measured by

unic-sdlc-orchestrator-1, 2026-09-17 22:55 CEST, reported on
#498. The third Box
(unic-dlc-pr-review) and the docs/boxes hard-coded line were found confirming that report in this
map's charting session.

Start with the bootstrap and PR-base logic at the cited lines in unic-dlc-build.yaml, unic-dlc-qa.yaml, and unic-dlc-pr-review.yaml, then read the configuration entries in README.md and commands/setup.md. Check the build documentation and ADR convention, and use the listed git ls-remote command plus /build and /qa to trace the current behavior. Done means the chosen design can express the intended base branch, keeps build, QA, and review consistent, and updates the documented rule and criteria.