tests: Extend generated-config contract coverage for OpenCode

Keep the generation contract and its shell-backed fixture checks aligned across all generated targets, including OpenCode. Add negative fixtures for decision-gate ownership and workflow-language drift, and register them in the flake and test harness.

Author: davidabram

.agents/skills/sce-change-to-plan/SKILL.md

@@ -6,17 +6,13 @@ description: >
 
 # SCE Change to Plan
 
-## Execution contract
-
-Own this workflow from input through its terminal user-visible response.
-Follow its steps, gates, and stops in order; do not add, skip, reorder, or merge them.
-Keep internal phase results private and continue immediately until a defined wait or stop.
-Resume user waits in this same skill and session.
-Render user-visible output only from the named workflow layouts or phase reports.
-Do not expose raw internal state or add text around a rendered layout or report.
-Non-SCE helpers may assist, but must return to the active step without changing
-phase order, gates, waits, writes, validation, stops, or terminal output.
-Do not invoke another SCE skill, package, or workflow command.
+## Purpose
+
+Own this workflow from input parsing through its terminal user-visible response.
+Execute the phases below directly and in order. Phase statuses are internal state,
+not inter-SCE workflow handoffs. Do not invoke another SCE skill, sibling SCE
+package, or SCE workflow command. Follow the canonical workflow's steps, gates,
+and stops exactly as written: never invent, skip, reorder, or merge a step.
 
 ## Phase references
 
@@ -37,6 +33,26 @@ Read a step's reference before taking any action for that step, not after. Read
 only the reference for the step you have reached: a run that stops at the
 bootstrap gate never authors a plan, which is why they are separate files.
 
+## User-visible output
+
+Use `references/output.md` for every gate and terminal response. Render no raw
+internal state. The reference contains only human-visible Markdown layouts.
+User-visible output is limited to those layouts: never invent a layout, and never
+wrap one in an added preamble, commentary, summary, or extra section.
+
+## Composite control flow
+
+Keep phase results as internal state and continue immediately whenever the
+canonical workflow says to continue. Stop only at a user wait or terminal branch.
+Any workflow-defined user wait resumes this same skill in the same session.
+Never expose an internal phase result
+as the workflow's final response.
+
+Relevant non-SCE skills may be used as helper capabilities during the active step.
+They are not workflow handoffs: when a helper returns, control returns to the active
+step. Helper use must preserve the canonical phase order, gates, waits, writes,
+validation, stops, and terminal user-visible output.
+
 ## Input
 
 `invocation input` is the change request, in free-form prose.

.agents/skills/sce-change-to-plan/references/context-load.md

@@ -61,15 +61,15 @@ sentence.
 
 ## 1.5 Return the brief
 
-Return one internal result with one of these statuses:
+Set exactly one internal state:
 
 - `loaded`
 - `bootstrap_required`
 
 Report facts the workflow can act on. A brief that only lists file paths has
 moved no knowledge.
 
-Return only the internal result. Do not add explanatory prose before or after it.
+Record only the internal state. Do not add explanatory prose before or after it.
 
 Step 2 consumes a `loaded` brief verbatim and treats its `key_facts` as recorded
 current state, its `gaps` as areas with no durable context, and its `drift` as

.agents/skills/sce-change-to-plan/references/output.md

@@ -48,7 +48,7 @@ candidate plan paths and explain that naming one candidate resolves it.
 
 This plan is a draft. State a correction and it will be updated.
 
-Next step:
+Next up:
 
 {next-task-id} — {next-task-title}
 
@@ -66,22 +66,22 @@ This is chat output, not a file. Nothing here is written to the plan.
 
 ## Layout
 
-```markdown
+```
 # Plan: {plan.name}
 
 Path: {plan.path}
 
-## Summary
+## Summary:
 {plan summary}
 
-## Tasks
+## Tasks:
 1. {task.id} — {task.title}
 2. {task.id} — {task.title}
 
-## Assumptions
+## Assumptions:
 - {assumption}
 
-## Open questions
+## Open questions:
 - {open question}
 ```
 
@@ -93,13 +93,13 @@ not carry.
 - `Plan:` — `plan.name`. Append ` (updated)` when `plan.action` is `updated`.
   Render nothing extra when it is `created`.
 - `Path:` — `plan.path`, exactly as returned, so it stays runnable.
-- `Summary` — `summary`, as prose. This is the only place the reader learns
+- `Summary:` — `summary`, as prose. This is the only place the reader learns
   what the plan actually does, so never omit it and never replace it with a
   restatement of the task titles.
-- `Tasks` — one numbered line per entry in `tasks`, in plan order. Append
+- `Tasks:` — one numbered line per entry in `tasks`, in plan order. Append
   ` (done)` to any task whose `status` is `done`.
-- `Assumptions` — one line per entry in `assumptions`.
-- `Open questions` — one line per entry in `open_questions`.
+- `Assumptions:` — one line per entry in `assumptions`.
+- `Open questions:` — one line per entry in `open_questions`.
 
 ## Empty sections
 
@@ -108,15 +108,15 @@ explicit `None.` confirms nothing is pending.
 
 When `assumptions` is empty:
 
-```markdown
-## Assumptions
+```
+## Assumptions:
 - None.
 ```
 
 When `open_questions` is absent:
 
-```markdown
-## Open questions
+```
+## Open questions:
 - None.
 ```
 
@@ -132,21 +132,21 @@ When `open_questions` is absent:
 
 ## Example
 
-```markdown
+```
 # Plan: red-sce-banner
 
 Path: context/plans/red-sce-banner.md
 
-## Summary
-Renders the ASCII-art SCE banner at the top of `sce` help in red instead of the current gradient. Color-disabled output is unchanged, and no other help surface is affected.
+## Summary:
+Renders the ASCII-art SCE banner at the top of `sce` help in red instead of the current gradient. Colour-disabled output is unchanged, and no other help surface is affected.
 
-## Tasks
+## Tasks:
 1. T01 — Render the SCE banner in red
 
-## Assumptions
+## Assumptions:
 - "SCE letters" refers to the ASCII-art banner in top-level help.
 - Red is uniform terminal red when colors are enabled; plain ASCII remains unchanged otherwise.
 
-## Open questions
+## Open questions:
 - None.
 ```

.agents/skills/sce-change-to-plan/references/plan-authoring.md

@@ -5,18 +5,18 @@ Run this phase for step 2 of the workflow, and again for each revision in step 4
 Input: the change request, and the complete `loaded` brief from the context load
 phase. Pass the brief verbatim; do not restate, summarize, or reinterpret it.
 
-This phase owns the planning process:
+This phase exclusively owns:
 
-- Resolve whether the request targets a new or an existing plan.
-- Challenge the change and run the clarification gate.
-- Derive plan-specific content from the request and loaded context.
-- Decide task boundaries, dependencies, and ordering.
-- Write or revise exactly one `context/plans/{plan_name}.md`.
+- Resolving whether the request targets a new or an existing plan.
+- The clarification gate.
+- Normalizing the change summary, acceptance criteria, constraints, and non-goals.
+- Slicing the task stack into one-task/one-atomic-commit units.
+- Writing `context/plans/{plan_name}.md`.
 
-`references/plan-template.md` is the sole owner of the persisted plan schema.
-Read its `Acceptance criteria rules`, `Task rules` and `No validation task` rules,
-and `Updating an existing plan` rules before authoring or revising. Apply those
-rules rather than restating them here.
+Do not duplicate any of it elsewhere in the workflow.
+
+Use the document format in `references/plan-template.md`. Read it before writing
+the plan file.
 
 The workflow renders this phase's result as the summary defined in
 `references/output.md`.
@@ -27,7 +27,7 @@ responsibility.
 
 The context brief is the durable memory this plan starts from. Treat its
 `key_facts` as recorded current state, its `gaps` as areas with no durable
-context, and its `drift` as recorded context that no longer matches the code.
+context, and its `drift` as context the code has already outrun.
 
 When no brief is supplied, load the context named by the change request before
 authoring, and follow the selection discipline in *Inspect relevant context*.
@@ -48,9 +48,8 @@ undecidable.
 Determine whether the request targets a new plan or an existing plan in
 `context/plans/`.
 
-When it targets an existing plan, read that plan before authoring. Apply the
-`Updating an existing plan` rules in `references/plan-template.md` when writing;
-this step only resolves which plan is being revised.
+When it targets an existing plan, read that plan before authoring. Preserve its
+completed tasks, their recorded evidence, its structure, and its terminology.
 
 When multiple existing plans match and none can be selected safely, return
 `blocked` with the matching candidates.
@@ -152,16 +151,33 @@ Do not explore the entire repository by default.
 
 ## 2.5 Author the acceptance criteria
 
-Derive the plan-specific success outcomes and checks before slicing tasks, then
-apply the `Acceptance criteria rules` and exact section shape in
-`references/plan-template.md`. The template owns their generic validation
-semantics and placement.
+State how the finished plan is proven, before slicing tasks.
+
+Each criterion describes observable behavior of the finished system and names the
+check that proves it. Record repository-wide checks once under `Full validation`,
+and the durable context the change must be reflected in under `Context sync`.
+
+`/validate` runs this section after the last task completes. It is the only place
+a plan says how it is validated.
 
 ## 2.6 Author the task stack
 
-Slice and order the plan-specific work after the acceptance criteria, applying the
-`Task rules` and `No validation task` rules in `references/plan-template.md`.
-Do not restate those generic task rules here.
+Slice the work into sequential tasks `T01..T0N` using the task format and the
+atomic slicing contract in `references/plan-template.md`.
+
+Every executable task must be completable and landable as one coherent commit.
+Split any task that would require multiple independent commits. Convert broad
+wrappers such as `polish` or `finalize` into specific outcomes with concrete
+acceptance checks.
+
+Order tasks so each one's declared dependencies precede it.
+
+The last task is an ordinary implementation task. Do not author a trailing
+validation-and-cleanup task, or any task whose only purpose is running the full
+check suite, verifying durable context, or removing scaffolding.
+
+Confirm every acceptance criterion is satisfied by at least one task. When one is
+not, the task stack is incomplete.
 
 A finished stack always leaves at least one incomplete task, so the workflow can
 always hand off to `/next-task`. When the request resolves to a plan but produces
@@ -171,32 +187,50 @@ by completed tasks, set internal status `blocked` with category
 
 ## 2.7 Write the plan
 
-Write `context/plans/{plan_name}.md` by applying `references/plan-template.md`
-exactly. For revisions, apply its `Updating an existing plan` rules.
+Write `context/plans/{plan_name}.md` using `references/plan-template.md`.
+
+When updating an existing plan, keep completed tasks and their evidence intact,
+and append or renumber new tasks without disturbing recorded history.
 
 ## 2.8 Return the result
 
-Return one internal result with one of these statuses:
+Set exactly one internal state:
 
 - `plan_ready`
 - `needs_clarification`
 - `blocked`
 
-Return only the internal result. Do not add explanatory prose before or after it.
+Record only the internal state. Do not add explanatory prose before or after it.
 
 A `plan_ready` result always names the next task in `next_task`, and carries the
 `total_tasks` count and any open questions the summary needs. Step 3 renders those
 without recomputing them.
 
 ## Plan authoring tone
 
-Write user-facing questions and open questions directly and specifically.
-
-- Ask only about material concerns that can change scope, success criteria, or task ordering.
-- State the concern and the concrete evidence for it.
-- Name a smaller or safer alternative when one is known.
-- Do not invent concerns, add praise or reassurance, or repeat the same concern in several forms.
-- When the user overrules a concern, record the decision and continue. Do not reintroduce it as a constraint, non-goal, or task.
+Every question and open question this phase writes is read by the user. Write
+them the way a senior engineer talks in review: direct, specific, and unbothered
+by the possibility of being unwelcome.
+
+- Ask about the thing that actually worries you, not a safer neighbouring thing.
+  A question you would not bother asking a colleague is not worth the user's
+  attention either.
+- State a doubt as a doubt. "I do not think this is worth the two tasks it
+  costs, because X" is useful. "It may be worth considering whether this aligns
+  with broader goals" is noise.
+- Name the alternative you have in mind. A challenge with no proposal behind it
+  is just friction.
+- Do not open with praise, do not close with reassurance, and do not apologize
+  for asking. Do not pad a doubt with hedges to make it land more gently.
+- Be persistent, not repetitive. Ask once, plainly, and let it stand; do not
+  restate the same doubt in three shapes to give it more weight.
+- Being disagreeable is not the goal. Being easy to agree with is the failure
+  mode. A plan the user waves through without reading has cost them nothing and
+  bought them nothing.
+
+When the user overrules a doubt, record it and move on. Do not relitigate a
+decision the user has made, and do not smuggle the objection back in as a
+constraint, a non-goal, or a task.
 
 ## Plan authoring boundaries
 
@@ -215,7 +249,8 @@ Do not:
 - Run task execution.
 - Synchronize context.
 - Run final validation.
-- Write a plan that violates `references/plan-template.md`.
+- Author a validation, cleanup, or context-verification task. `/validate` owns
+  that phase.
 - Set internal status `plan_ready` for a plan with no incomplete task.
 - Create a Git commit.
 - Author more than one plan.

.agents/skills/sce-change-to-plan/references/plan-template.md

@@ -129,7 +129,6 @@ invent one: `None.` is the expected answer for a well-specified change.}
 
 ## Task rules
 
-- Number tasks sequentially as `T01..T0N`.
 - Every task is a checkbox line so progress stays machine-readable:
   `- [ ] T01: {title} (status:todo)`.
 - Author each executable task as one atomic commit unit by default.
@@ -146,9 +145,9 @@ invent one: `None.` is the expected answer for a well-specified change.}
 
 - The last task in the stack is an ordinary implementation task. Do not author a
   trailing "validation and cleanup" task.
-- Final validation and success-criteria verification are run by `/validate`
-  from the `Acceptance criteria` section after the last task completes. Validation
-  reports cleanup or repair work that is still required; it does not perform that work.
+- Final validation, cleanup, and success-criteria verification are run by
+  `/validate` from the `Acceptance criteria` section after the last task
+  completes.
 - Do not author a task whose only purpose is running the full check suite,
   verifying durable context, or removing scaffolding.
 - A task may still create or update durable context when that context is part of