I read this as a test-first production fix across the gateway onboarding/check-in lifecycle - I’ll audit every profile-package origin check, reproduce the configured installed-package binding failure, make the smallest consistent fix, and verify the full related test surface without touching live state or Git.


I’ve completed the origin audit: the lifecycle has three production checks—registration, onboarding runtime, and activation cutover. Registration already honors `DUALCOACH_PROFILE_PACKAGE`; runtime ignores it, and cutover only honors an explicit CLI argument, so both later stages can reject the same valid installed package. I’m moving to the isolated-process regression test first, then will align those two checks while preserving workspace fallback.


The regression now fails at the exact live guard (`runtime.py:85`, “outside configured profile”), confirming RED without relying on cached modules. The production change is in place for runtime and cutover, and I’ve added cutover sibling coverage while retaining the existing registration environment-binding test; verification starts with these three origin checks before the broader lifecycle suites.


The three origin-check proofs are GREEN, and ruff plus compileall are clean. The LSP tool is workspace-confined to the parent project and refuses the explicitly scoped sibling repository, so I’ll record that tooling limitation and use the repository’s `ty` checker as the source diagnostics fallback while running the complete related bootstrap/onboarding/check-in test set.


The combined 462-test process exposed an existing collection-order cache collision: onboarding tests import the repository venv package during collection, while bootstrap fixtures intentionally validate a different default package root; 459 passed and 3 bootstrap checks then rejected that cached foreign module. The production files type-check clean, and the focused bootstrap files pass together (13/13), so I’m isolating the established package-root test domains into fresh pytest processes rather than weakening origin enforcement or editing unrelated fixtures.


I read this as a completed test-first lifecycle fix - the source candidate is ready to reseal, not deployed.

Implemented consistent `DUALCOACH_PROFILE_PACKAGE` resolution while preserving `<profile>/workspace/checkin_cli` fallback.

Changed:
- `gateway/platforms/telegram_nutrition_onboarding_runtime.py:6,82-87`
- `gateway/platforms/dualcoach_activation_cutover.py:8,391-395`
- `tests/gateway/test_telegram_nutrition_onboarding.py:7-11,129-172`
- `tests/gateway/test_dualcoach_activation_cutover.py:208-251`

Origin checks audited:
- Registration: already honors environment binding.
- Onboarding runtime: fixed environment binding.
- Activation cutover: fixed environment binding, with explicit CLI argument retaining precedence.

Evidence:
- RED: isolated subprocess failed at `runtime.py:85` with `nutrition onboarding module is outside configured profile`.
- GREEN: runtime regression, cutover sibling coverage, and registration environment coverage each passed.
- Related suites: **462 passed** across isolated package-root domains.
- Combined-process run: 459 passed, 3 pre-existing collection-order module-cache collisions; no production enforcement was weakened.
- Ruff: clean.
- Compileall over `gateway` and `tests/gateway`: clean.
- Production `ty` diagnostics: clean.
- LSP tool was attempted but rejected the sibling repository as outside its fixed workspace; changed-test `ty` output contained only pre-existing diagnostics.

No live profile, evidence, configuration, service, deployment, or Git metadata was modified.