Session prompt tells a run on an out-of-org repo to file issues into MyThingsLab

[lorenzoliuzzo]

Found while running my-coder for real against lorenzoliuzzo/supervised-learning-on-food-images, a repo outside the org.

_PROMPT hardcodes the org in both escape hatches (coder.py:49-66), and the rendered prompt is org-literal regardless of --repo:

If this issue turns out to be blocked by a missing capability in ANOTHER
MyThingsLab repo ... Use `gh issue create --repo MyThingsLab/<repo>` ...
  FLEET-DISPATCH-BLOCKED: MyThingsLab/<repo>#<number>

... file it immediately with `gh issue create --label critical --label bug
--repo MyThingsLab/<repo>` ... That label halts new fleet dispatch org-wide

ALLOWED_TOOLS permits Bash(gh issue create*) with no repo restriction, so this is a live cross-org side effect, not just confusing text: a session working on a personal repo can file into MyThingsLab, and the critical label it is told to use halts fleet dispatch org-wide — a target repo my-coder was merely pointed at can stop the fleet.

The invariant in CLAUDE.md ("never touches a repo other than the one named by the issue it was given") is contradicted by the prompt itself, which is the only reason the deviation is not visible in the code.

Two further prompt assumptions leak fleet-specific house style into an out-of-org run: the Rules block mandates from __future__ import annotations and type hints on every signature, which may contradict the target repo's own CLAUDE.md — the very document the prompt calls "authoritative here".

Acceptance criteria

• The blocker and critical-bug paragraphs derive their org from the target repo slug, or are omitted entirely when the target is outside the fleet.
• The FLEET-DISPATCH-BLOCKED: sentinel and its parser agree on the derived org.
• The fleet-specific style mandates defer to the target repo's own conventions when it supplies a CLAUDE.md.
• Tests covering an in-org target (unchanged behaviour) and an out-of-org target.