mellions-issue-resolution-proposallisted

<!-- Mellions Engineer | LetA Tech Ltd. | leta@letatech.ca --> # The plan goes on the issue A plan that lived only in a session is lost with the session, and the issue then has no trace of what was intended, what was approved, or what "done" was supposed to mean. The proposal is one comment on the issue, written before any code, that a reviewer can approve, whoever implements it can follow, and the closure method can read the acceptance rule from without re-deriving it. ## The repository's approval model decides what the comment is Read the repository's `CLAUDE.md` and whatever issue process it carries under `.claude/skills/` before writing. Three postures exist and the repository declares which: - **Approval before code.** The comment is posted and the work waits for a named authority's word; no approval, no implementation. Where the authority gave the approval with refinements, the comment carries the refinements, verbatim, and they supersede the original plan. - **The gate is at merge.** The comment is the implementer's plan, posted without claiming approval and saying so — "awaiting ratification at merge" in the comment itself — and the human decision moves to the pull request. - **Delegated.** Where the partnership delegates the work, the comment is the record and you proceed; the standard of the plan does not drop with the ceremony. Never claim an approval that was not given, never soften a conditional one, and never backfill a proposal after the cod