1.16.0 — A customized out-of-the-box Classic section now migrates onto its existing Freedom page — on top of its layout or in the Classic one — and the build no longer starts on a plan you have not approved

A customized out-of-the-box Classic section now migrates onto its existing Freedom page — on top of its layout or in the Classic one — and the build no longer starts on a plan you have not approved. You pick at the start of the build whether the client's Classic changes are added into the Freedom page as it is, or the page is re-laid so fields and details sit where they were in Classic. The standard Freedom Feed, Attachments, Connected to and Timeline stay as they are. The engine itself now refuses to cut, split, start, add or route build tasks until the exact plan version is approved, and keeps the task ledger intact when a run is killed or two runs start at once.

🧩 Customized out-of-the-box sections

• Two ways to reconcile onto the existing Freedom page (#238). On the first task cut, --reconcile-mode overlay (the default) keeps the Freedom layout and adds the client's Classic delta into it; --reconcile-mode classic-layout moves base fields and details to their Classic positions, inserts the planned ones and removes base layout controls that are not in the plan, while keeping Freedom-only additions. The plan is the same for both modes; the choice is frozen in the task folder and stamped on every task, and verify flags any leftover element in classic-layout.
• Standard Freedom components are kept, not migrated again (#238). When the Freedom page already has Feed, Attachments, Connected to or Timeline, their Classic counterparts close as "standard Freedom component kept" instead of being rebuilt next to them.
• Verify reads a reconciled page correctly (#238). Fields match by their bound column, so moved base fields no longer show as missing; the form-template row closes on a reconcile; and an already registered section is not registered again while its list page stays a real deliverable.

🔒 A build you approved, and a ledger that survives

• No build tasks before the plan is approved (#261). --tasks, --split, --start, --add and --route refuse to write anything unless decisions.md approves the exact plan version the manifest renders. The refusal names the expected version and every version that is approved, so a stale approval is easy to spot.
• A killed or parallel run no longer tears the task ledger (#260). Task files, index.md, the split file and timings.json are written atomically, and timings.json is updated under a lock, so two concurrent --start calls cannot put two sub-agents on the same artifact. A busy ledger stops with a clear timings-locked or ledger-busy message that says to re-run.

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.

1.14.0 — Converting a Freedom UI web page to mobile no longer needs a feature flag

Converting a Freedom UI web page to mobile no longer needs a feature flag. The Web→Mobile page converter is generally available from clio 8.1.0.137: the toolkit stops asking you to run clio experimental --name mobile-page-converter --enable and simply checks that your clio has the converter. The same release makes the conversion report say what each missing target page really is, and keeps branding previews out of the chat unless you ask for them.

📱 Mobile conversion without the flag

• The converter works by default (#243). The preflight checks whether the converter is available instead of whether a flag is on. If your clio does not have the converter yet (it ships ungated in clio 8.1.0.137), the skill tells you to update with dotnet tool update clio -g and re-run the request. The engine side is clio#1725. If you enabled the Beta flag on an older clio, the converter keeps working there; once you update to 8.1.0.137 or later, the leftover "mobile-page-converter" key in clio's appsettings.json is an orphan that nothing reads — harmless, and safe to delete.
• Supported scope is the Mobile canvas (#243). Tablet layout is still generated, but it stays experimental and outside the supported scope, so the plan asks you to check the page on a tablet before relying on it.
• Each missing target page says what kind it is (#222). Instead of the same "no Freedom UI mobile page found" on every row, the report tells a web page whose button binding was blanked apart from an object whose default mobile page was not found, so you can see which buttons are already dead and which only need a page registered.

🎨 Branding

• Logo and background previews are no longer rendered by default (#69). The agent describes them in words and draws a preview only when you ask to see one.
• You see which package the branding goes into (#65). The recap before applying names the target package, and the closing summary repeats the package the theme actually landed in.

🔧 Install and update

• A failed update prints the hint that matches its error (#232). When updating one agent fails, the message follows that agent's actual error, such as a deleted branch or a locked file, instead of one generic hint for all of them.

🛠️ Developer tooling

Repository tooling only — not part of the installable release asset.

• Merging a release preparation PR releases it (#226), and the toolkit-release repository skill cuts a release end to end (#227).
• The migration engine has coverage and lint (#223), its npm test runs from the engine folder (#230), and the zero-runtime-dependency rule is written down, with the SRI check accepting only sha256/sha384/sha512 (#233).

1.13.0 — Building an approved Classic → Freedom migration plan no longer depends on one long agent session

Building an approved Classic → Freedom migration plan no longer depends on one long agent session. Step 7 now cuts the plan into a folder of task files and walks it one task at a time, each in its own build sub-agent: progress survives a killed session, the chat shows what is running and how long it should take, and "done" is decided by the engine's verify table instead of by the agent that did the work. The same release teaches mobile conversion to handle pages a converted page opens that do not exist on mobile yet.

🗂️ Migration build as a task folder

• The approved plan becomes a folder of tasks (#175). migrate.mjs --tasks <dir> writes one file per task plus a derived index.md, built from the same rows --checklist and --verify use. Each task names the artifact it writes (writesTo:) and the tasks it waits for (dependsOn:), so two sub-agents never write the same page body. A small run is one build task and one separate review.
• You see progress while the work runs. --start <id> marks a task in progress before it is dispatched, and every run prints a --- progress --- block with the running task, its elapsed time, a measured time range and what is left. Durations are kept in timings.json and replace the default estimate once four tasks have closed. --next names every task that can start right now with the exact --start command, and says what holds the rest (#194).
• Repair is a task, not an improvised loop. --verify --built b.json --tasks <dir> prints the step 8 table and writes the open rows back as repair tasks, grouped by page and cause. A cause that fails three repair rounds is parked instead of retried again, and a row whose inputs have not changed since the last round is reported as DISPUTED or STALLED instead of spending a round (#205).
• A run ends on one migration result report (#190, #192). --verify --tasks <dir> writes a report whose verdict needs both the task ledger and the built pages to agree: every task closed, nothing left not built without a decision, every machine-checked item present. It is written for the person who owns the migration — what needs a decision comes first — and a run that is not complete exits 2 with ⛔ RUN NOT COMPLETE.
• The engine composes the verify payload itself (#191). --verify --from <migration-folder> builds built.json from the reads each task recorded, so the orchestrator no longer types it by hand; --built <file> stays as the offline replay path.
• Your scope decisions go through the engine (#197, #207, #209). --decide / --revoke record wont-do or postponed on a row instead of hand-editing task files, and decided deliverables are listed before the first dispatch. A task waiting on another task's open decision is held back by --next and refused by --start with the source row named.
• Each deliverable reaches exactly one sub-agent (#175, #207). Every task carries an agentNonce:; the engine reports a nonce repeated across tasks and a done task without one. A task with nothing left to build is not dispatched. A task closed with no dispatch record fails the run (#184), and so does a plan row no task claims (#198).

✅ A green verify means the page works

• A page that cannot render no longer passes (#175). crt.FileList and crt.DataGrid are checked for columns and items, not only for their type.
• A review verdict closes a row only when its write-up is reachable and belongs to that row (#202).
• Correctly built pages are no longer reported as missing (#203). Five verify-side false negatives from a live run are fixed, among them decisions written as a table, controls nested under menus, and phone and email inputs.
• The list page gets the form page's treatment, and nothing in the plan misses a task (#188). Work written only into plan.md now reaches the build tasks too, and a section's dashboards are emitted once, not once per child page.
• Feed and Attachments use the canonical settings on any page template (#182).
• Virtual attributes are declared before the handlers that write them (#206), and Feed / Attachments merge-vs-insert is left to the builder, which sees the page (#200).
• Every refusal exits non-zero across --tasks, --next, --route and --start (#199), and the CLI refuses an unknown flag instead of ignoring it.
• A new app is placed on an existing object in one create-app call (#175) through optional-template-data-json, instead of create-app plus create-app-section leaving duplicate pages.

📱 Mobile conversion: pages that do not exist on mobile yet

• Missing target pages are reported and can be converted (#183). Before converting, the skill checks for an existing mobile page to reuse. Pages a converted page opens but that have no mobile version are listed in the plan and the final report; the skill offers once to convert them, one page at a time, each through its own gate, then points the blanked binding at the new page. The engine side is clio#1562. No published clio carries it yet (the newest is 8.1.0.134): the flow works from the first clio release after 8.1.0.134, and until then the skill leaves the section out of the plan and the report.

🛠️ Developer tooling

• Sonar gate, the Sonar exclusion check and gitleaks run on pull requests into any branch, not only into main (#210). Repository CI only — not part of the installable release asset.
• A comment-hygiene check fails the build on comments and test titles that record review history instead of the rule (#196, #204).

1.12.0 — Your Classic section's dashboards now reach Freedom UI instead of quietly disappearing

Your Classic section's dashboards now reach Freedom UI instead of quietly disappearing. A section's dashboards live in stand data, not in schema code, so migration never saw them and dropped them without a word. The toolkit now discovers them, puts them in the plan you approve, installs the Dashboards Migrator through clio, hands the migration over and verifies the result. The same release stops a section's own declared elements from being dropped, rewrites the migration plan for the human who approves it, and repairs mobile conversion against the converter's new response shape.

📊 Classic dashboards migrate instead of disappearing

• A section's dashboards are found and shown in the plan (#153). Discovery resolves them from stand data and records each dashboard's delivery mode — packaged or stand-only — so --plan stays non-zero until the question is answered; present:false is a valid answer.
• The Dashboards Migrator is installed for you (#178). When a section has dashboards and the stand carries no migrator, the skill installs it with clio install-dashboards-migrator after confirming the environment with you, and leaves running the migration to you in System Designer. A clio too old to carry the verb records a gap instead of blocking the migration.

🧩 A section's own elements reach the plan

• The section schema's diff is read, not ignored (#176). Classic→Freedom diff handling existed for page schemas only, so any element a section declared reached nothing — the same button migrates from a page and was dropped from a section. The section's own diff is now folded and mapped into the list ChangeSet.

📝 A migration plan a human can read

• Worklists carry What-it-does and Use-case columns (#179). Custom methods and other declared logic are described in human terms instead of mechanical Trigger / Body-does / Reads→writes columns, and the ⚠ Confirm block is leaner. Rendering only — what gets built did not change.

📱 Mobile conversion follows the converter

• The skill reads the fields the converter actually ships (#180). The build step iterated guide.elementMap, which the converter no longer returns, so it produced an empty page body — and validation passed on it. The skill now names guide.viewConfigDiff and guide.droppedElements.

🧭 Page and app creation guidance

• Fields that are not finished alone get their companion (#174). Amounts and totals ask for the analytics that make them useful, via new mandatory rules, reference sections and checklist items in the guidelines skill, plus a supporting tweak to app-orchestrator. Guidance only — no tooling changes.

1.11.0 — Installing the toolkit into Codex CLI now actually gives you the skills

Installing the toolkit into Codex CLI now actually gives you the skills. The Codex install step called a codex plugin add subcommand that does not exist, so every Codex install failed silently and no CAADT skill was ever available in a Codex session — this release fixes that end to end, install and update. It also teaches Classic → Freedom migration to convert classic card widgets through the migrator instead of asking you to hand-build a chart substitute.

🔒 Codex CLI install fixed

• --target codex installs a working plugin (#168). The installer no longer calls the non-existent codex plugin add. Instead it does what Codex itself needs: copies the plugin runtime into Codex's install cache (<codex_home>/plugins/cache/<marketplace>/<plugin>/<version>/) and appends enabled = true for the plugin in config.toml — the same two things the interactive /plugins browser writes. Verified on Codex 0.153.4: all seven toolkit skills show up in a session.
• Updating Codex no longer leaves a stale cache. Codex is updated by reinstalling from the release source, so an old cached version is removed rather than sitting beside the new one. Running the update twice changes nothing the second time, and a stale cache with a missing plugin block ends up with exactly one version and one block.
• The docs stopped advertising a command that never worked. README and docs/install.md now describe the installer path and the /plugins browser instead of codex plugin add.
• Claude Code, Copilot CLI and Cursor install and update exactly as before.

🗺️ Classic → Freedom migration

• Classic card widgets are migrated, not re-invented (#149). A classic CardWidgetModule used to come out of analysis as a vague generic component, which left you hand-building a chart or list substitute. Each card widget that carries both of its coordinates is now recognized as its own card-widget decision with its widget key, record id and resolved region, so the plan converts it through the migrator's ConvertCardWidgetsProcess and places what the process returns. Widgets missing a coordinate still degrade to a generic component rather than guessing, and a conversion that fails stays blocked instead of being replaced by a fabricated stand-in.
• The plan carries each widget through to the layout, the confirmation step and the verification checklist, so nothing is converted without showing up for review.

🛠️ Developer tooling

• The clio dev-toolchain build can target a single .NET framework. A new TFM config key for build-dev-toolchain (e.g. net10.0) uses a two-pass restore so the override does not leak into netstandard2.0 project references (#150). This is repository build tooling — it is not part of the installable release asset.

---

1.10.0 — Your Classic pages are now read from their real source before a migration plan is written

Your Classic pages are now read from their real source before a migration plan is written. A plan run can also no longer report a partial surface as complete. This release sharpens the analysis and planning side of Classic → Freedom migration: a new classic-ui-expert skill that describes every customization on a Classic surface with the source that proves it, a shared Freedom mapping table the whole engine agrees on, and a behaviour-analysis workflow that runs the same way on Claude and Codex. Building the Freedom pages themselves is unchanged in this release.

🔍 Classic behaviour analysis

• A new classic-ui-expert skill (#147). Ask what a Classic section, record page, mini page or detail actually does, and you get every customization with what it does, why it exists in business terms, and the exact source that proves it. It reads the stand only, and it declines instead of guessing when a source is unreachable.
• The analysis runs as a workflow, not as a single long prompt. classic-behaviour-analysis.workflow.js and its host-neutral core (skills/_workflow-core/) split the surface into work items with their own run state, so a long analysis survives a dead call and replays identically instead of starting over. Claude and Codex adapters run the same core; a CI drift gate fails the build if the generated workflow stops matching its source.
• A run that can only see part of the surface stops instead of announcing full coverage (#147). On a measured run the analysis returned 1 of 18 declared scopes and still logged 547/547 after 1h51m. It now stops with a named cause before spending a single description.
• Method names are counted per schema. Six schemas each having an onSaved used to collapse into one row, so 413 rows were counted as 399 and one description closed six of them. Keys are qualified at one point, and an answer that cannot be attributed is named rather than dropped.
• The merge phase is retried — it was the only phase whose death left full coverage and no deliverable — and a page reachable from several parents is handed off once, not two or three times.

🗺️ Migration planning

• One mapping table for Classic → Freedom, checked against a registry (#147). Element recognition, target selection and the generated component index come from the same source, so the plan and the engine can no longer disagree about what a Classic element becomes.
• The plan says what it could not place. A coverage gate, imperative-logic and imperative-members worklists, section boundary resolution and a placement gate all run at plan time, so unplaceable behaviour is listed for you instead of quietly disappearing between plan and build.
• List pages are planned as their own change set, and the --stubs handoff folds analysis results back into the plan.

🛠️ Developer tooling

• Bundled workflows are mirrored by the installer, generated output is excluded from Sonar analysis, and .gitattributes pins the generated files to LF so a Windows checkout runs them unchanged.

---

1.9.0

Every toolkit workflow now reports product telemetry, not only app creation, and a host-side hook makes sure a session is counted even when the agent forgets to. Edit, migration, mobile-conversion and branding runs were invisible to usage analytics; this release makes them countable with the same opt-in consent, the same privacy rules and no change to how you work. It requires clio 8.1.0.119 or newer (dotnet tool update clio -g).

📊 Telemetry for every flow

• One stage vocabulary for all workflows (#96). Agents report the same stages for every flow (workflow_started, plan_approved, build_started, work_item_completed, workflow_completed, ...) plus a workflow field naming the flow, so app maintenance, Classic to Freedom migration, mobile page conversion and branding land in the same funnel as app creation. The vocabulary is owned by clio (get-guidance name=product-telemetry); the toolkit only says where each flow emits and what counts as a unit of work.
• A guaranteed floor on Claude Code. A small hook runs after the first clio MCP call of a session, records one session-start event and reminds the agent which session id and toolkit version to report. It is also registered for the prompt and response events, which Claude Code fires in every project; in a session that never calls clio it returns at once and writes nothing. Cursor gets the same rules through an always-applied rule the installer writes, Codex through AGENTS.md; Copilot CLI has the skills only.
• Session cost is reported from the host's own transcript, once per response, as the real total rather than a guess made inside the run.
• Consent and privacy are unchanged. Nothing is sent before you grant telemetry consent, the hook never answers that question for you, events carry no prompts, generated content or credentials, and withdraw-telemetry-consent turns everything off at any time.

🛠️ Fixes

• clio installed under C:\Program Files is found again (#96). A CLIO_CMD path with spaces was split at the space and clio was reported as missing on the default Windows install location.
• An older clio degrades quietly. If the installed clio does not accept the new vocabulary, the toolkit reports nothing for that run and writes one diagnostic line naming the cause; upgrading clio restores reporting.

---

1.8.0 — Your Freedom UI web pages can now become mobile pages — in beta, if you opt in

Your Freedom UI web pages can now become mobile pages — in beta, if you opt in. The Web → Mobile page converter is open for beta testing behind a clio feature flag that stays off until you turn it on, so nothing changes for anyone who does not ask for it. The same release lands a long reliability pass on Classic → Freedom migration: the plan is checked against the real stand before a build starts, --verify no longer reports success it cannot back up, and the whole workflow now runs the same way on Claude, Codex and Copilot.

📱 Mobile page conversion — beta, opt-in

• Convert a Freedom UI web page into a Freedom UI mobile page. The creatio-mobile-page-conversion skill drives a gated flow: it asks clio for a conversion guide, shows you a plain-language plan, and writes nothing until you approve it (Gate M) — and registers nothing as a mobile section until you approve that separately (Gate S).

• You must turn it on, and you need a recent clio. The converter is gated behind clio's mobile-page-converter feature flag, which is off by default:

  clio experimental --name mobile-page-converter --enable
  

  Requires clio 8.1.0.118 or newer (dotnet tool update clio -g). On an older clio the skill stops with an enable message even after you flip the flag, because the underlying MCP tool is not there yet. The toolkit deliberately pins no clio version — the compatibility boundary is the MCP tool contract, checked at runtime.

• The plan tells you it is a beta. Every conversion plan opens with a plain-text Beta notice, so the state of the feature is visible at the moment you are asked to approve a write (#106, #141, #142).

• What is in scope: Freedom UI web form pages and list pages/sections. Classic pages must be migrated to Freedom UI web first; already-mobile pages are rejected. The converter is advisory — it returns a guide and the page body is built and validated through create-page / validate-page / update-page, not generated blindly.

• What still needs you afterwards: mobile manifest and wizard wiring, plus anything the guide flags as requiresManualDecision, droppedRequests or flaggedActions. Do not enable the flag on a production environment.

• The engine's mechanics are documented once, in one place (#87), so the skill's process description and the engine description can no longer drift apart.

🔬 Classic → Freedom migration: fewer confident wrong answers

• A plan is validated against the real stand before the build starts (#102, #133) — including asserting the plan's identifiers against what actually exists, so a build no longer discovers halfway through that it was planned against something else.
• --verify is trustworthy (#109, #124) — business rules, component role matching and list columns are actually checked, an inconclusive live check no longer outranks the run's own record (#123), and a verifier reads back only the round it ran (#134).
• The gates say what they mean. A correctness gate blocks on correctness rather than severity (#121); a completeness gate runs in context before a unit closes (#111) and no longer treats a short build as an incomplete one (#131); UI-guidelines evidence is recorded before a unit closes (#108) and a page that is already diffed-and-compliant can file it (#122).
• Your answers reach the builder. A decision you gave on a ⚠ Confirm item is carried through to the build action, or the run says why it could not be (#104, #119), and the worklist asks one question at a time instead of bundling several into one (#97, #98).
• Recognition and mapping are registry-backed — one shared Freedom mapping table (#114), component targets resolved by kind with typed {kind, id} identifiers (#116, #136), generator-mirrored Classic element identification (#105, #125), and per-output deprecation carried through the registry index (#127).
• Build execution is faster and easier to follow — each build unit gets its own row of the queue and its own built file (#107, #138), and the Freedom build executor's phases were optimized (#112).
• Reconcile respects both size caps — the schema definition and the runtime output — and retries a bounded number of times with repeated-rejection triage (#137, #140).
• Reading the stand survives a wedged MCP path by falling back to the clio CLI (#93, #103), list pages are emitted as a ChangeSet gated off the built page (#100), resolved Classic list columns are used in plans (#91), and the on-save duplicate check is surfaced as a fourth on-stand signal (#113).

🧩 One workflow, three hosts

• The orchestration core is host-neutral (#115, #139) — Claude, Codex and Copilot run the same workflow instead of three drifting copies. Bare subagents are counted rather than passed off as a verified workflow (#144).

💰 Cost reporting you can reconcile

• Cache tokens are reported and cost is split by agent (#101), usage is de-duplicated by message.id rather than by JSONL record so a retried message is not billed twice (#126), and transcripts are classified against the run record (#135).

🎨 Branding

• A favicon is applied whenever the logos are (#92), so a branded app no longer keeps the stock browser-tab icon.

🛠️ Developer tooling

• A local build-dev-toolchain rebuild script (#143), now cross-platform for Windows, macOS and Linux (#146).
• Workflow scripts are pinned to LF so a Windows checkout can run them (#83).

---

1.7.0 — Your new app now lands where users can actually find it

Your new app now lands where users can actually find it. Until this release the toolkit could build a complete Creatio app that nobody but an administrator could open — create-app drops every new section into the My applications workplace, which is granted to System administrators only, and nothing ever asked where the app really belonged. Navigation placement is now a required discovery question, asked in the first batch alongside the business questions and carried through the plan, the runbooks and the completion criteria. The same release fixes the reason the orchestrator was often skipped entirely, and sharpens what the Classic and mobile migration skills tell you they could not convert.

✨ What's new

• Navigation placement and audience are settled before anything is built. The first discovery batch now asks which workplace your section — and its home page — belongs to, and which roles should see it, offering a new workplace named for the app, My applications, or one you name. Asking later was never a smaller version of the same thing: it made you re-decide work that was already finished. When a section is added to an app that already exists, the recommendation is refined during requirements gathering by reading where that app's sections actually live — and deliberately never recommends My applications back to you, because an app sitting there is the very problem this question exists to catch. (#77)
• The orchestrator is selectable from a plain request. Its description named only the toolkit's own artifacts — "Business Plans", "implementation handoffs" — so "create a Todo app" or "add an Orders section" could miss it entirely and fall through to raw clio MCP with none of the toolkit's gates applied. All three trigger surfaces — the Claude skill, the Cursor rule and the OpenAI manifest — now carry the same user-intent wording, and a test keeps them from drifting apart again. (#77)
• Embedded profile cards migrate to the Freedom side profile. A Classic page that carried an embedded profile card now maps onto the Freedom side profile instead of being flattened into the main layout. (#71)

🛠️ Straighter answers about what did not convert

• Mobile conversion names the whole containers it dropped. It reported only per-element drops, so a web container removed up front never appeared in "what was dropped" — you found out by noticing something missing. (#78)
• Mobile page conversion emits targeted diff operations instead of one root merge, so a converted page changes what it needs to and leaves the rest of the mobile template alone. (#73)
• Classic → Freedom migration reads sources from the runtime only. The hybrid runtime-plus-repository model is gone, so a migration can no longer be planned from a local checkout that disagrees with the environment it will be applied to. (#66)
• A Flow & Engine explainer for the migration skill now lives in the repository, so the documentation can be read and edited alongside the code it describes. (#67)

🔒 Fewer surprises in what gets applied

• Custom CSS is a last resort, and you are asked first. Freedom UI guidance now tries native component properties before reaching for CSS, and warns and confirms before applying any. (#57)
• A missing guidance topic stops the run instead of improvising. Navigation writes depend on clio's workplaces guidance, which ships with the clio knowledge library from 1.13.0 onward. If it is unavailable the run stops and tells you, rather than guessing the write — a workplace bound with the wrong columns installs on the next environment as an unreachable entry and cannot be repaired by re-installing. (#77)

---