Generated plan-mode preamble incorrectly claims skill precedence over host restrictions

The generated plan-mode preamble asserts that a skill can take precedence over the host's plan-mode restrictions. A skill cannot grant permissions or redefine the host's active collaboration mode. This creates contradictory instructions across every skill that includes this shared preamble.

Verified against main at 71f6048e8ada25180e61438abc1d98cb151fe9a7, in [generate-completion-status.ts, lines 21–29](https://github.com/garrytan/gstack/blob/71f6048e8ada25180e61438abc1d98cb151fe9a7/scripts/resolvers/preamble/generate-completion-status.ts#L21-L29).

The source contains the phrase “skill takes precedence over generic plan mode behavior” and also declares filesystem writes / nested Codex execution permissible merely because they inform a plan. Whether those operations are allowed depends on the host and the user's authorization. The same file later describes a telemetry write as an unconditional plan-mode exception.

Reproduction (instruction-level, no model invocation required):

1. Inspect `generatePlanModeInfo` and `generateCompletionStatus` at the pinned revision.
2. Render or read a skill that includes this preamble.
3. Use it in a host whose plan mode is read-only except for a designated plan file. The generated text and host restrictions now conflict.

Expected: state that host/system restrictions and current user scope take precedence; use only host-permitted planning operations. Prior user authorization should be reused where the host permits it. A skill cannot declare its own exception to read-only mode. Missing an optional workflow tool should not prevent independent permitted work.

Suggested narrow fix: replace the blanket plan-mode permission statements with host-aware language, and explicitly limit STOP/approval checkpoints to unresolved decisions. Keep real destructive-action consent and genuine read-only constraints.

I also found an unconditional missing-AskUserQuestion stop in an older local installation, but verified that current main already has an interactive fallback. That old behavior is not being reported here as a current defect.

Validation boundary: this report establishes a source-level instruction conflict. It does not claim an observed permission bypass or a measured model-performance regression.

Start in scripts/resolvers/preamble/generate-completion-status.ts at generatePlanModeInfo and generateCompletionStatus, using the pinned revision and the rendered skill preamble as the baseline. Check the generated wording against a read-only host scenario. Done means the preamble no longer claims precedence over host restrictions or unconditional exceptions, while permitted planning and approval behavior remain explicit.

Written by the indexing model from the issue text.