Setting the file. One moment.
Subchapter 28.25
references/phases/generate/generate.mdMarkdown12 KBView on GitHub
CONSENT GUARD (check before anything else): This phase runs only by explicit opt-in (the decision is the product; execution artifacts are opt-in). If
.phase-status.json→ is not : when this turn’s user message is an explicit Execute request (“generate the Terraform”, “create the migration scripts”, or Decision-gate choice C), set (read-merge-write) and proceed; otherwise STOP — do not generate anything — and re-present the Decision gate (or the decide-complete resume offer) from / .
run_mode"decide_and_execute"run_mode: "decide_and_execute"estimate-assemble.mdSKILL.mdTransform the design + estimate into migration artifacts in $MIGRATION_DIR/: a
terraform/ directory, MIGRATION_GUIDE.md, README.md, migration-report.html
(stakeholder summary + optional what-if scenarios), database migration scripts,
generation-warnings.json, and validation-report.json (the Terraform
policy-gate verdict the assembler produces after all fragments — it runs the
tf-best-practices policy checker against the final terraform/ directory, and
the read-only completion gate then reads that verdict).
Terraform for each Elastic Beanstalk web service
is intentionally incomplete until the customer supplies that app’s required
application port and health check path. Non-web Elastic Beanstalk services do not
require those web-only inputs. This is the multi-artifact phase.
Composed of the terraform + docs + report fragments + an EKS-generate fragment + one
cross-artifact validator assembler (declared in the frontmatter
_fragments/_assemble); the interpreter runs each fragment whose _trigger is
true, then the assembler. The eks-generate fragment is an ALTERNATIVE compute
path — it fires only when the design has an eks_cluster (its _when trigger),
emitting eks.tf + kubernetes/ manifests. Templates are output skeletons
(templates/generate/...); the fragments are the routing algorithm. Read each unit
file for its own contract; the assembler owns the cross-artifact completion gate.
This phase covers artifact generation ONLY.
FORBIDDEN — Do NOT include ANY of:
Your ONLY job: Transform the design into migration artifacts. Nothing else — with two
exceptions. Running the tf-best-practices policy checker against the generated terraform/ and
applying its fix_hints is part of producing the artifacts: the assembler does this after all
Terraform-producing fragments (Generate is dispatched at _exec._agent: rwx, which grants exactly
the scoped shell the checker needs — nothing else). Running the report validator over
migration-report.html is a separate, main-window exception: the dispatched worker’s shell is
scoped to the policy checker only (it cannot run the report validator), so that check is part of
finishing the artifacts and happens in the “Finish Generate” step below, after the worker
returns. Design/estimate decisions stay final.
This is leftover Generate work, not a gate check: the dispatched _exec._agent: rw worker
that assembled the report has no shell (INTERPRETER.md § capability tiers — rw excludes Bash),
so it could not run the report validator. The interpreter finishes that work in the MAIN window
(the only place with a shell), after the worker returns and before running _postconditions.
Run the report validator (required, blocking):
python3 "<SKILL_BASE>/scripts/validate-heroku-migration-report.py" \
"$MIGRATION_DIR/migration-report.html" --migration-dir "$MIGRATION_DIR"REPORT_OK → stamp the durable result so the gate reads an artifact, not conversation
memory: write $MIGRATION_DIR/report-validation-status.json as
{"report_status": "REPORT_OK"}, then continue to the gate. REPORT_FAIL → write
{"report_status": "REPORT_FAIL", "errors": [ … ]} and emit GATE_FAIL, pasting the
validator’s errors[] verbatim so the user knows exactly what failed (missing scope id,
empty cost-optimization, a banned badge-verdict-* pill class, a <th> without scope,
missing <html lang>, etc.). This step does not edit the HTML.
If the validator cannot run at all (no shell on the host), do not write
report_status: "REPORT_OK" — leave the stamp absent (or not_run) so the gate fails closed.
Then the _postconditions gate runs (read-only): the section-id _assert plus the
report-validation-status.json _assert above. The gate runs no validator and edits nothing (per
INTERPRETER.md § _postconditions, a gate never mutates artifacts to pass).
Recovery on GATE_FAIL: fix the report from the pasted errors[] — either hand-edit
migration-report.html, re-run the validator directly, and re-stamp report-validation-status.json
on REPORT_OK; or a maintainer re-runs Generate for a clean rebuild. Do not rely on “just
re-run Generate” as the fix path in prose: re-dispatch re-authors the report under the shell-less
worker, so the pasted error list is what makes the next attempt actionable.
report-validation-status.json is a temp status sidecar (like the policy sidecar) — not a
_produces artifact; it exists only to carry the validator result across the worker→gate boundary.