[ahrazzle]

Asks about contribution mode at install time, with a safe default.

What

• install.sh takes --contribution-mode off|on (default off) and, when switching on, a required --operator-ref <reference>.
• After a successful install the composer writes the contribution-state record at records/CONTRIB-STATE.md, rendered from the protean-ops ingredient's own installed template. The composer still vendors nothing: no schema copy, no submodule.
• tests/test_contribution_mode.py covers the toggle in 8 cases; the workflow gains one step that runs it.

Why

External contribution is a public side effect, so the mode that permits it belongs to the operator and needs a default that fails safe. The composer is where a fresh machine decides it, so the question and its safe answer belong beside the command that asks it.

Behaviour

input	result
no flag	mode recorded as off; nothing else changes
--contribution-mode on without --operator-ref	exit 1: a permission a flag alone can widen has no audit trail
--contribution-mode on --operator-ref <ref>	record written with the mode on and a switch row citing the reference
--contribution-mode maybe	exit 1
ops ingredient not in the selection, mode off	exit 0 with a reported note; no record written
ops ingredient not in the selection, mode on	exit 5 rather than inventing the schema
record already present	left unchanged; an install never silently widens a permission

No environment variable is introduced: the choice is a recorded, reviewable flag rather than an ambient HERMES_* setting.

Evidence

command	result
python3 -m unittest tests.test_contribution_mode	Ran 8 tests, OK
python3 -m unittest tests.test_kit_lock	Ran 28 tests, OK
python3 build/check-lock.py kit.lock.json	PASS, ingredients=7
python3 build/check-ingredient-contract.py --lock kit.lock.json	PASS, ingredients=7, unverified=0
python3 build/install.py --all --target <tmp> --dry-run --contribution-mode on --operator-ref OP-9	exit 0, prints contribution mode: on (operator reference OP-9)

Pre-existing, not caused by this change — the repository's build/verify-all.py reports 7 of 10 steps failed on main because it invokes build/sweep-gate.py, build/review-gate.py, build/surface-scan.py, build/check-artifact-contract.py, preflight/check.py, report/check.py, and build/generate.py, none of which exist in this tree; the workflow's Verify surface-scan passes step exits 2 for the same reason. Those gates are untouched here, and this change does not make them worse: check-lock.py, check-ingredient-contract.py, and both unit-test files pass.

Open item — the pins in kit.lock.json are not re-pointed by this change. The matching ingredient changes travel on their own branches, so the re-pin follows their release tags rather than this commit.

[ahrazzle]

PASS WITH OPEN ITEMS

Audited head: bcfe50e
Scope: gate-runner migration plus doctrine/ops/control-plane v1.1.0 lock repins.
Evidence: verify-all 4/4; check-lock --verify; ingredient-contract --verify; tests 28 + 8; CI 3.11 and 3.12 green in run 35247254474.
Independent QA: Shaka re-QA cleared D1-CI and D1-PIN for the three lane ingredients; mode off/on/operator-ref, internal always-on, external_contrib kill-switch, selected installs, and no-overwrite were read back.
Open item: the pre-existing protean-handoff stale pin still blocks a full --all install; it is outside this PR and lane scope.
Merge approval: green exact head; merge is permitted only with --match-head-commit bcfe50e.