I1990 — The pre-push check judges the refs being pushed, or says why the checkout's task binds them

○READY wave 0 · p3 · deep-work profile · parallel safe

Part of adopter-upgrades — An adopting repository survives a Majordomus upgrade, and what the tool vendors into it is adopter-neutral.

Objective

Decide whether `finish --check` in the pre-push hook should read the refs git passes on stdin and judge only those carrying the active task's branch, and implement or document the decision.

Why

In OSCILLA, pushing branch X from a checkout whose task is on branch Y fails with different_context, so feature branches were pushed from the main checkout as a workaround. Binding a task to its branch is coherent with one task per checkout and one branch per worktree; the hook ignoring which refs are pushed is the part nobody decided.

Current state

lib/finish.sh ignores the hook's stdin; mj_validate_state compares the checkout's branch with the task's.

Desired state

The decision recorded (decision or ADR) and the hook's behaviour matching it, with a case.

Scope

• lib/finish.sh
• share/skeleton
• docs/CLI.md
• test/cases

Dependencies

None. This issue is a root of the graph.

Acceptance criteria

• Pushing a ref other than the task's branch is judged by the recorded rule, proven by a case

Validation

• bin/majordomus plan validate
• MJ_TEST_JOBS=4 bash test/run.sh <the case this issue adds>

Evidence required

• prepush_refs_case
• decision_recorded

Evidence

Timeline

started

—

verified

—

completed

—

Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.

Canonical record: .ai/repo/project/issues/I1990.yaml. Read it back with majordomus plan show I1990.