1.15.0 — A Classic → Freedom migration now gets through real customer layer chains to an approvable plan, and builds only what is left to build

A Classic → Freedom migration now gets through real customer layer chains to an approvable plan, and builds only what is left to build. Removes and merges of elements no layer defines no longer block the plan, a section that already has a Freedom UI version asks you once whether to extend it, and every decision you take while planning is applied before the first build task starts. The built pages carry the Classic texts in every culture, child pages open from their related lists, and verify closes a row only on an element that proves it.

🧭 Plans that reach approval

• Leftover removes and merges no longer block the plan (#221, #244). A remove or merge of an element that no layer and no seed defines has no effect in Classic, so it becomes a closable note instead of a hard block. Children placed in a lower layer under a container a later layer removes are removed with it, as Classic does, instead of surfacing as unresolved parents. Mini, typed and child pages no longer report their own structure as incomplete.
• An existing Freedom section is extended or kept, by your choice (#247). When the Classic section already has a Freedom UI section for the same object, the agent asks once before the plan: extend the existing pages (the default) or build a parallel section. Extending creates a new package with clio's create-package, available from clio 8.1.0.137.
• More detail add mechanisms are recognised (#241, #253). Details that add records through openProductLookupToLink or openLookupWithMultiSelect are planned as "add by picking from a lookup", not as plain related lists. Detecting such an add declared only in a detail's base layer needs the detailSchemas.<detail>.bodies field from clio#1743, which is merged but not in a published clio release yet.
• Removed row actions of a detail are migrated (#229). When a Classic detail removes Copy, Edit or Delete from its row menu, the plan says to build the list without them and keep open-on-click; an override the engine cannot read is reported for a manual check instead of as "nothing removed". The read-only list rule in creatio-ui-guidelines now includes the Open-only row menu recipe (#246).
• Each run says which skill build, clio and stand it used (#218, #235). The run starts by printing the skill version with its branch and commit (read from the plugin registry when the install has no .git), the clio version and the stand's Creatio version and database. The same block appears in worklog.md and in plan.md, so a failed run can be reproduced without asking what was installed.

🧱 A build that starts from your decisions

• Decisions taken during planning are applied before the first task (#228, #237). Every deliverable has a stable id and a status. A deliverable you dropped, or one the engine already found nothing to build for (such as a Print button with no printables on the stand), reaches its task closed, so no sub-agent spends time on it. A planning decision that no deliverable accounts for stops the task cut with the exact fix, before anything is dispatched.
• A "build it" answer reopens the row through the engine (#231). --decide D<N> --build reopens a row that waited on a decision, without hand edits that set off drift warnings; --route names the rows still waiting on a decision.
• You choose where the build runs (#240, #251). After approval the agent asks once: start a new session from the printed resume prompt (recommended, every build step starts small), continue in this session, or compress this session and continue. The choice is recorded in worklog.md.
• The build works on Claude Code, Codex and Copilot CLI (#215). Step 7 settles how it dispatches build sub-agents on the current host before the first task, and asks once when the session does not allow sub-agents.
• Rebuilt child pages open from their related lists (#254). Each rebuilt child page gets its own wiring task that binds it to the related list that opens it, and verify checks the binding on the stand.
• Agents carry less and read only what they need (#213, #216, #236, #239, #245, #250). The migration SKILL.md is split by who reads it and when, from 185 KB to under 95 KB at the start of a run. Each build and review sub-agent gets a brief with the facts it needs, documents are read in parts instead of whole, and a build task runs one bounded browser check.
• Quality-gates records exist from the first task (#249). The record files are created when the plan is cut into tasks, and each page's last build task files its own quality-gates record.
• A split that would build in the wrong order is refused (#212). A split that places a virtual attribute after a handler that writes it is refused before anything is written.

✅ Verify that matches what was built

• Texts come from Classic in every culture (#242). Related-list titles follow the Classic order (page caption, then the detail caption on the page, then the detail's own caption), detail messages are taken word for word, and every Classic culture is carried and verified. This needs resourceStrings from clio 8.1.0.137 (clio#1723); with an older clio the plan says translations are not migrated.
• Card-action rows close only on an element that performs the action (#217, #234). Print and Process need a button that sends the matching request, each custom card action gets its own row, and a *Visa detail is verified as Approvals.
• Built elements are matched by name and type, not by type alone (#220, #186). An unrelated button no longer closes a row that expects a specific one, and fields and rules bound with an agent-style $PDS_<Column> binding are recognised.
• A large manifest piped on macOS is read in full (#219). migrate.mjs - <mode> no longer fails with "cannot read manifest from stdin", and the verify report is no longer cut short when written to a pipe.

📜 Instructions for every host

• The attribution policy no longer assumes Claude Code hooks (#256). The shipped instructions ask for change attribution only when the host has an attribution integration installed; a public install uses the normal Git workflow with no invented markers or commit trailers.